The filters are in one easy to find tab and they are all configurable with a few mouse clicks.
BIP-110 is not "configurable". It is based on consensus rules, which is far worse, than using only standardness rules.
By the way: it is interesting, that Knots decided, that the risk of forking into a minority chain is better, than just validating a subset of the existing network. Because if your goal is to remove the spam, then BIP-110 won't do that on all blocks, which were already produced. It won't improve Initial Blockchain Download in any way, and it won't make validation easier, if OP_RETURN will be replaced with OP_CHECKSIG, OP_SHA256, and other things. Spammers will adjust, and validating a new spam will be harder, than validating the old spam.
If they would really want to make things "configurable", then they would still follow the heaviest chain of Proof of Work, but they would just process only a subset of it. But instead, they decided, that it is better to try to force new rules on everyone, rather than making a lighter node, which would skip the spam, and encourage users to use it, by improving its performance.
But on Bitcoin when you send a dickbutt.jpeg you are effectively putting a burden on all the 90,000 nodes by forcing them to host and share your stoopit dickbutt.jpeg, until the end of time.
This is not true. Existing nodes are processing everything since 2009, but as the chain will grow further, then it won't scale at some point. And then, I would be really surprised, if people in 2109 will still start their nodes from 2009, and process 100 years of history, only to handle some transactions, which were created in the 22nd century. Reorging the chain beyond some point would be so disruptive, that it would lead to a different coin, if you would see for example 210,000 or more blocks being reorged. Currently, miners can spend coins after 100 blocks, and a chain reorg bigger than 288 blocks would break some pruned nodes, by forcing them to re-download missing data. Even a chain reorg bigger than 100 blocks could lead to a different coin.
I still wonder, why pruning is not implemented in the way Satoshi described it. Because the idea is to prune only spent things, and leave everything else, where it is. But instead, nodes don't store blocks or transactions from 2009, even if they are unspent, while also they store N last blocks, even if some coins are spent, and could be safely discarded. Which is completely different from Satoshi's model, where spent things are pruned, and unspent things are kept (because they are needed to validate next blocks). And if it would be implemented in this way, then pruned nodes could always refer to all unspent coins, which is the main thing users care about. Only coin owners have to keep the history of their spent coins, for everyone else, knowing what is unspent, is sufficient to process new things, which is the only thing they care about.