they do not have that many good options on the table
There are many good options, which they simply don't want to use.
1. They didn't have to fork, to remove the spam. If they would process only monetary transactions, and skip everything else, then they would land on the same chain, and would have a faster node. Processing a subset of the mainnet traffic is not a sin, this is one of many reasons, why we have Merkle Trees.
2. There was no need to skip the failing state, and enforce new rules, regardless of the hashrate. If you activate a soft-fork, while having 2.5% hashrate, then you have 40 times slower chain. It is simple math, no matter if you think about BIP-110, or any other proposal. To successfully build on top of a minority chain, you really need a lot of other protections. If you don't have them, then you risk 51% attacks, or a halted chain, when your supporters will give up, because of burning electricity on mining, and getting unspendable coins.
3. When they reached their own minority chain, they didn't have to change the Proof of Work. Having even 2.5% of the network is still in a scale of many EH/s. That's a lot of mining power. If you change it, then you basically encourage all miners, who supported you in the past, to switch to mining different chains. Because firing the miners obviously means, that they won't stop mining: they will be your competitors instead.
4. If you decide to enable Merged Mining, then make sure, to trace the global difficulty, and require that, to reach 51% attacks. If you have your own, local difficulty, enforced and traced locally, then someone can have 1% on a stronger coin, and 60% on your coin, without any costs.
You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.
Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.
Read it, piece by piece, and compare it with naive implementation of Merged Mining, used by NameCoin, and copy-pasted almost everywhere else. Can you see anywhere, that each chain should have its own difficulty? Can you see a global difficulty, splitted between many chains, and "tied together by a Merkle Tree", or many difficulties, and separate, loosely connected networks, where stronger chains can attack weaker ones?
Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
Which means, that to attack a smaller network successfully, you need to have 51% of the global hashrate, not the local one, coming from one of the subnetworks. And how it is implemented almost everywhere? Well, you have one difficulty for Blake chain, one difficulty for Sia network, one difficulty for that chain, another difficulty for another one. And the end result is that you can attack smaller ones, without having 51% globally. And then, it is easy to spread FUD about "Merged Mining being bad", when people just keep copy-pasting the same buggy implementation to each altcoin, hoping that this time, miners from one stronger chain somehow won't attack weaker ones, even though consensus rules, coming from these weaker chains, give them a lot of incentive to do that without any costs.
Also, Luke should know exactly, why naively implemented Merged Mining can be harmful, because
he killed CoiledCoin in this way. So, it is something, known for decades, and he should be aware of the risk of using some mining algorithm, which is used by others, and enabling a naive Merged Mining implementation on top of it. Hmm, what could go wrong?
Since they are trying to do everything possible to make this into a thing, going deeper into their cultism, their actions will continue to get more desperate.
We live in times, where access to the information is easier than ever. If you are wrong, then there is no need to go deeper, and make more mistakes. It is always possible to come back, think it through, and write a better code. Satoshi spent months, even years, working on things from 2007 to 2009, and constantly improving everything, until it was good enough to be released.
Releasing next patches, without planning everything carefully in advance, will turn it into a testnet. Or even worse: a warnet, where everyone would have a lot of incentive to prove, that your network is unsafe.
