Part of the reason why the Core side is a loser in the spam debate is that they generally prefer arguing from feelings and emotion, whereas the Knots side relies more on technical arguments
It depends on what you find harmful
In this post, Chris Guida outlines why he thinks spam is particularly harmful: https://x.com/cguida6/status/1968117953871720463
Blocks are persisted to disk, which is abundant
The mempool is stored in ram, which is scarce
Therefore spam is more harmful in the mempool than in the blockchain
Ram is more precious than disk space, that's why 1tb of ram costs way more than 1tb of disk
I prioritize efficient use of the scarcer resource
I think constructing the utxo set after each block creates a cpu bottleneck
The teem "ineffective" in your first premise provides a clue to its faultiness: it embeds a negative into a key term, and when this term is unpacked, we discover that you are really assuming a universal negative: namely, that there is no other purpose beyond the one you identify as ineffective. Proving a universal negative is, of course, really difficult, and a semester of philosophy might teach you this.
A clean mempool is desirable because it keeps your disk space ready for better uses than storing other people's spam
Regarding your syllogism, your first premise fails of configuration options have any other purpose beyond keeping data off the blockchain. And they do: the primary purpose of mempool policy, for example, is to police your mempool, not your blockchain.
Syllogistic logic supports mempool filters:
(1) If the filters clean your mempool, then they work
(2) They do clean your mempool; witness: your eyes
(3) Therefore, the filters work
Yeah, it has that in common with the swiftsync proposal
A guy at btc++ Istanbul had an interesting project. He downloads the blockchain without checking for doublespending. After he has all the data, he does a doublespend check by running an efficient sorting algorithm called MergeSort, which, in his implementation, takes all "input" utxos and "output" utxos, sorts them alphabetically via txid_vout, and removes duplicates. Those are always outputs created in one tx and spent in another
The result is a list only containing unspent outputs, i.e. the result is the utxo set, and this procedure gives him a sync speedup of slightly over 50%. It also does not seem to require storing an "intermediate" utxo set *during* ibd
I wonder if is wise to do ibd with that method, and then apply the utreexo accumulator procedure to the utxo set once it gets created at the end of ibd. The result would be, you only need the full utxo set once during the lifetime of your node: you need it at the end of ibd, and only to construct the utreexo accumulator. After that, you don't need the utxo set, unless you want to help others sync the same way
I'd rather draw the cracks
My phone screen cracked but I can't share a screenshot because it's on the surface so the screenshotter doesn't see it
Can phone devs do something
Bart, wake up! They're coming to spam your mempool! https://video.nostr.build/dcae080dd880eff46968f73d61626f604a38166a012f88a04fdad1d0fc48a29b.mp4
More knotzis should give Floresta a try
It's all about filters! ;) 
I think inscriptions are dumb and I don't want them in my mempool
I also think people who like them ought to be free to make them
In one way the problems date back to v25 in May 2023. Inscriptions came out shortly before then, and v25 made no attempt to apply the datacarrier limits to this method of embedding arbitrary data in bitcoin.
My hope is that the same fear of stale blocks induces miners to not mine large op_return txs
To make that fear more grounded, I hope more people filter such txs
Good point, I missed that
Current state of Bitcoin Core
https://video.nostr.build/ccfafdc454aec96f140d7fc57a97835fe9fe3c343e5466dcaabbf7be6121f94c.mp4
ah, wait...I don't think it *can* produce the proofs without access to the full utxo set...hmm...