This only works if the spammer is kind enough to use OP_RETURN or the Taproot/Ordinals method.

If he uses a collection of fake pubkeys (Stampchain ...), then you cannot prevent any data to be stored on your node. Not only will it be stored in the blockchain date (which you can prune later), but also in the UTXO set which you need to validate transactions.

That's why I consider this "incentive problem" so critical, and judging from the Bitcoindev discussion it was one of the main reasons triggering the decision, alongside with the problem that standardness "violations" are currently happily added by miners and thus there is danger that there's no "common mempool policy".

There was a proposal to implement a check that pubkeys must be "real" (i.e. be on an elliptic curve), which means additional ressources needed for tx validation, but it could be worth it if it really was a solution to the problem.

This would however make the spam only more expensive for the spammer as he can grind through "real pubkeys which contain his spam data", so if he still wanted damage he could. Even Luke-Jr seems to have admitted (he didn't answer anymore to that thread in the discussion) that the additional validation effort wasn't worth it.

My hopes in this field lie basically in new methods to store blockchain, where you could store a set of proofs without storing the complete data. Haven't heard if there was progress on this though.