Transaction malleability has nothing to do with the security properties of zero conf, it only allows you to change the signature of a transaction, not the contents. So if you malleated a transaction, you would still end up with a transaction paying the merchant, in no way vanishing like you describe. What does affect the security is if miners violate the first seen rule, which is not a consensus rule, to include transactions that were seen later but have higher fees into their blocks. This allows you to essentially replace a transaction by bribing a miner with a higher fee. Generally the risk of this is seen as low, generally lower than the risk of credit card fraud, so for low value transactions it is generally fine. Malleability breaking the withdrawals of an exchange is a problem with that exchange, not with Bitcoin Cash.

As for developers removing the malleability fix (SegWit) to break the LN, that is just a plain lie. First, SegWit was removed because it is just an hack that can be achieved in much better ways. SegWit is such technical debt because it did in a soft fork what should have been done in a hard fork. Second, you can see on the development mailing list that fixing it has been discussed well, and a fix for third party malleability is actually already active. You can also see that nobody is against 2nd layer systems like Lightning Network, and it will be supported if and when it is actually useful.

The EDA that was in place in the first 3 months was indeed a big mistake and has since been replaced with a well performing fast acting DAA, but it is not the reason people push for 0-conf. 0-conf was a pretty well used and working feature of BTC before the blocks first became full. It is only logical to use it again on a chain that does not intend to let its blocks become full.