The difference is that you are much more likely to get prosecuted or at least deplatformed for hosting something illegal like malware or csam than a leaked cable.
It is not just law enforcement involved here - it's also platforms' terms of service.
There is no legal precedent for this yet, but what happens if some litigious person in the mold of Craig Wright tries to sue users he/she doesn't like with this pretense?
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.
Public key validation would work if those were being used to store the spam, but what happens if it's address hashes a la base58 or bech32? Verification becomes impossible as the key is not even known.
The primary way to defend against spam is to increase the transaction fees. However, given that we have just on-boarded fractional sat/vbyte transactions, the only way something that is going to come about is naturally via transaction congestion.
Which means to say, the more active users there are making transactions, the less spam will be mined on-chain, because spam transactions are inherently larger and competition for block space will push the fee rates up.
The other method we have is to enforce transaction (not block!) pruning as an optional command-line option, by using a bloom filter to completely ignore Bitcoin eater addresses, invalid keys, OP_RETURN.
By the nature of bloom filters, a tiny amount of "word-addresses" that have known private keys will also be excluded, preventing the relaying of their transactions and also preventing them, and any descendants, from being verified successfully in case they are already in a block. I guess in that case they would be filtered out via RPC call unless another command line option makes it return those transactions in the RPC output as well.
And also
frotnendfrontend applications built on top of bitcoin can simply refuse to display harmful & potentially illegal transactions for legal liability cover.