To clear this up: the technique in the article is literally what we use in unit tests to check that our TX-based event code won't break under malleability. It's something that Bitcoin developers have been writing code around forever (and warning about just as long.) So truly: if there's anyone out there still writing code that assumes static TXIDs they really do deserve what's coming to them.
As I see it: the attack reaches critical mayhem in a similar way to accepting zero-conf transactions in that what you have is a consensus problem. The specific fix for TX malleability is to watch transactions based on their meaning, not their TXID (in this case "meaning" is looking at the inputs, outputs, version, timelock, etc to produce equivalent transactions.) And of course: don't accept zero-confirmation transactions.
Here's some of my ultra-1337 Python code for producing the "attack" just for laughs:
def mutate_tx(tx_hex):
"""
Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn't be used beyond testing as it uses an ugly eval() hack.
https://en.bitcoin.it/wiki/Transaction_Malleability
"""
tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
script_sig = repr(tx.vin[0].scriptSig)[9:]
script_sig = eval("CScript([OP_1, OP_DROP, " + script_sig)
tx.vin[0].scriptSig = script_sig
return b2x(tx.serialize())