CHECKLOCKTIMEVERIFY/BIP65 fixes payment channels without fixing transaction ID malleability, so non-malleability is only a requirement for payment channels to work when we want to free received channel value while keeping the same channel ready for new payments.
Technically, this could be solved by the client sending funds to two different outputs, and switching to output #2 while the settling transaction redeeming output #1 is being confirmed, and vice versa. It's a horrible hack, I know, but it works right now. Of course, the client app should take care of all of this, making it transparent to the user.
I agree with Poon and Dryja that 1MB won't be enough forever, but payment channels is a bit like fiber, the capacity is basically unlimited. If you keep a payment channel open for a week, and then close it, it's completely irrelevant whether you made a single payment or 1 trillion payments over that channel, since nothing touches the Blockchain. In other words: if we are able to clear efficiently enough, it's also technically possible to get by with the 1MB limit, simply because payment channels have unlimited capacity, as they don't touch the Blockchain.
> I'm not against PCs in principle, I just don't understand why the block size wasn't increased and then a fully tested version of LN being rolled out afterwards [..]
Because a fully tested version of the Lightning Network doesn't exist. When it does, this plan will make sense, but that's not yet.
Personally, I'm focusing my attention on something that I know is possible right now: consumer-to-merchant transactions using digital promissory notes issued in exchange for payment channel payments. It's not the most elegant solution, but unlike all other proposed solutions it actually can work right now.
Much like is the case with Bitcoin, by the way. When Bitcoin was released, cryptographers/mathematicians weren't really pleased with it because of its "inelegance". But, in the end, it works better than anything else and it works right now.