The fact that you have to ask this question proves you haven't seen my proposals ergo we did need a new topic.

To summarize the way to prevent this attack should have been the same method we have been using forever to prevent similar attacks and exploits. It could have been introduction of standard rules that would have made such malicious transactions non-standard hence majority of full nodes would have refused to relay them and that would have successfully prevented this attack from growing.
Standard rules are easy to implement too since they don't need a fork, we just had to get full nodes to run a patch for their old clients or run the newest release to enforce the new rule.

However, I don't see this method being effective anymore considering how the scam has grown big and the market size of it is considerable enough to encourage the scammers to run full nodes themselves without enforcing the said standard rule to relay their spam. There is also incentive for them to pay the miners behind the scene to mine their malicious transactions.

--snip--

At this point I'm afraid we need a soft fork to make these transactions invalid/illegal as part of the consensus rules which is much more challenging since it requires implementation, locked-in period, getting miners to vote and accept this fork, etc.
But that effectively and easily prevent this attack whilst keeping the protocol flexible for future improvements. For example the rule can only limit the witness size for version 1 program (similar to version 0) and leave any bigger size for any future possible usages (if they arise) to future versions which are already non-standard and not relayed by any of the full nodes.