Scripts are used in Bitcoin to prove authorization to spend the inputs in a transaction. Mimblewimble uses a quirk of CT such that only the owner of a set of inputs can create the transaction in the first place. The resulting transactions have enough structure that they can be merged and cut-through, and as @Matthieu says, after cut-through any scripts that may have been present are gone and unverifiable.

To answer your specific questions:

1. For multisig, n-of-n the parties create an output by summing public keys and then adding vH to get a Pedersen commitment. They then interactively produce a rangeproof. Doing a m-of-n version is a little more involved (the summing is replaced by some higher-degree polynomial) but essentially the same.
2. For locktimes, the transaction "excess", which needs to stay in the blockchain forever, can simply sign a minimum blockheight at which it's allowed to appear.
3. Atomic swaps, hash timelocked contracts, zk-contingent payments, Tumblebit, and a pile of other things require outputs that can only be spent by explicitly revealing some secret value (as opposed to proving knowledge of a secret value without revealing it at all, as signatures do). It's an open problem to construct a MimbleWimble output which has this property.

Note that you can get payment channels with just (1) and (2); hash preimages are only needed for HTLC Lightning channels, which are more efficient and have some other nice properties.

The incompatibility comes down to 2 main factors:

• Pruning: an important addition of the mimblewimble proposal is the ability to merge transactions across blocks. If transactions include scripts, merging becomes impossible as the script behavior is unknown. While for simple spends, it's fairly straightforward to eliminate matching amounts.
• No address: in mimblewimble the equivalent of bitcoin addresses (hash of a public key) don't really exist. There may be a way to still be able to send money for a contract but it'd be difficult for a contract to send money to anyone.