In this design, time locked transactions can be broadcast across the network and replaced by broadcasting a new transaction that uses higher sequence numbers. That's what the sequence number field is for. It was intended to allow arbitrary high frequency trading between a set of parties, though the "channel" notion is a simple way to think about the two party case.

The issue is that you can broadcast transactions with a lock time far in the future to fill up memory, and keep broadcasting replacements to use up CPU time and bandwidth.

Additionally, there is a school of thought that says Bitcoin must work even if lots of miners are malicious and willing to break arbitrary things in order to try and get more money. I don't think Bitcoin can really be a mainstream success under such a threat model, for a whole bunch of reasons (e.g. the economy relies pretty heavily on unconfirmed transactions), but under such a threat model there's nothing that forces miners to actually include the latest version in the block chain. They could pick any version. In the 2-of-2 channel model it takes both parties to sign, so clients can enforce that all versions have the same fee attached.

I disagree with Gregory that people refuse to use protocols that are affected by malleability. There aren't any user-friendly apps that use refunds currently, so we have no idea whether people would refuse to use them or not. It's an open question. The answer would probably depend on the real prevalence of attacks, which is currently unknowable and likely application specific.