In pretty much all cases, this was nothing more than a nuisance to end users. I have not read any reports of any entities losing money as a result of that attack (some may have lost
potential revenue as a result of not being able to accept 0 confirmation transactions, but I would not consider that in the scope of 'losing money as a result of that attack')
Same as the "spam attacks", yet somehow a lot of people think we need to do something about that in order to advance bitcoin.
The spam attacks cause everyone to pay more to get their transaction confirmed. If the max block size were increased then the cost of these spam attacks would grow exponentially, and the effectiveness of these transactions to decline.
Subsequent to that 'attack' the majority of nodes have been "programmed" to not relay high s-value signature transactions, so malleability has more or less been fixed for the end-user.
No, its not fixed. We just ignore all transactions. This causes issues for users using old software.
You can say the same thing about every soft fork. However users of non-full-node wallets
should receive notification that their transactions have been rejected, which should hopefully get them to upgrade. Full node users tend to be more active in upgrading, however they can view their transactions (or that their transactions have been rejected) on one of many block explorers, which might get them to upgrade in addition to the warning message to upgrade.
Non-upgraded users will probably not receive high s-value signature transactions because other upgraded nodes they are connected to will not rebroadcast such transactions, and because the overwhelming percentage of users will not even attempt to broadcast such transactions.
The only way that I am aware that a high s-value signature transaction to get confirmed is for a miner to accept such transaction directly and the only type of business that remains vulnerable to malleability are gambling establishments that allow for on-chain gambling (businesses that tentatively accept 0-confirmation transactions can ignore transactions in which there is an unconfirmed input to the funding transaction in order to prevent fraud).
Its working, yes. Is that the metric here?
I am not sure what you are saying here? I am trying to describe the small number of businesses that are affected by malleability under current node rules.