Name a Bitcoin version when the code was updated to "kick out spam". I'm not convinced that's ever happened. Why did we collectively not deem it necessary to change the code on any of the prior occasions people have spammed the chain out of greed or malice and yet suddenly it's imperative that we do so now? Where are you drawing the distinction?
There are loads of examples where we've introduced consensus and standard rules that prevented abuses and spams or made it extremely difficult:
- Block size limit set on very early days to be 1 MB max
- Limits on the size of coinbase script size to prevent miners from spamming the chain.
- Preventing people from abusing the lack of outputs' scriptpub validation to inject massive size arbitrary data to the blockchain by introducing standard rules
- Introduction of OP_RETURN rules so that people can use
that to inject their data into the blockchain but under controlled rules
- Limitations on data size that can be pushed to the stack in scripts
- Changes in fee and dust rules a couple of times over the year with the price changing
- Setting standard rules first and turning them into consensus rules regarding the dummy data in OP_CHECKMULTISIG(VERIFY) operations that could be abused to spam the chain like Ordinals does
- Same exact thing done with conditional operations' true/false stack item that could have been abused to spam the chain with junk
- Existing limits on number of OP codes, SigOp codes, etc. that a block can contain to prevent other types of attacks
- Limits on witness count and size for version 0 witness program
- Enforcing "empty stack" requirements after script evaluation ends to prevent junk data spam into the chain by abusing that (one or more junk data pushed to the stack at the end that will never be popped).
...
These are cases of the top of my head and almost all of them are abuse cases that are very similar to the Ordinals Attack.