Knots does not stop the spam from entering the blockchain, but it prevents it from being stored on your node which can remove you from liability in cases like what I mentioned.
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 data (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.
Anyway in this case, incentives are useless. The consideration is for malicious entities, they don't care about your incentives.
This is of course true. Neither of these methods/filters could do anything for a really malicious party, as they would use the most harmful method no matter what, and thus resorting to Stampchain and friends even with the OP_RETURN door wide open. But the not completely malicious but instead profit-driven folks could behave according to these incentives, see below.
The Taproot thing could have been solved, but alas we tend to open more doors than we tend to close for some reason.
I dispute the first part of your sentence. Yes, filters could have worked for some time, but it would have led in a cat and mouse game and much higher development/maintenance cost for Core.
And to the "open more doors": The fake pubkey door is the widest one open, and the most harmful. Yes, it is a bit more expensive than Taproot, but Taproot has also some disadvantages. The idea is thus, at least, to nudge the "de facto malicious" spam into OP_RETURN (i.e. not with the intention to attack Bitcoin, but to make profit with NFTs and stuff), before they get the idea to use the Stampchain method and we get much higher node operation costs.