302 is already bad, and 301 is already wrongly implement as RFC 2616 itself notes. Ultimately I doubt either is going to see a "fixed" implementation from a buggy one that's lasted as long as it has.
That doesn't answer the question, namely, "will loosening the definition for 301 make things worse than not changing it?". In this thread I've not seen a solid argument that it won't make things worse, only long redirections (ha!) from the point. Are you saying that 301 is so widely, badly implemented as to be a lost cause, as the author concedes 302 is?
I don't know enough about client implementations to say whether it is unsaveable, but let's say it is: why would 308 exist? That suggests the HTTP spec folks believe it's fundamentally changed meaning. With new-301, new-302/303, 307 and 308, we'd cover each of the 4 cases. Seems to strongly suggested that's necessary.
You can't just "let's say" 301 is unsaveable, because that's the only outside fact that determines whether TFA's argument is correct. You seem to be assuming that the committee's decision is evidence that it's a good idea, which is exactly what TFA is trying to determine.
Meanwhile, hobohacker got around to answering the real question.