The original design is documented at the bottom of here:

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

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.