With BIP 101, spammers can continue to spam blocks and know for certain that for a few years they can both start another debate and the cost of continuous spam does not change that much. With BIP 1xx, the cost of spamming full blocks will double every two weeks, thus making it incredibly expensive to maintain a prolonged spam attack on Bitcoin. With the same amount of money, a spam attack would last a shorter amount of time if BIP 1xx was implemented than with BIP 101.
It sounds like you have the idea of spamming blocks backwards. Spammers can't block legitimate transactions - the best they can hope is to delay no-fee transactions. A block isn't filled with the first transactions that a miner sees - the miner decides which transactions to include, based on the transaction size/priority/fee.
Those spam transactions can delay low fee transactions for a long time.
This is not what the block size cap is there to combat. The anti-spam limit of 1MB is there to prevent a spammer from filling the hard drives of every node operator. This is why we're not discussing moving to unlimited block size.
With BIP 101, there is no more incentive for spammers to attack than there is right now - and there has never been a spam attack in the history of Bitcoin.
Where were you a month ago when someone was spamming transactions? Don't give me BS about a "stress test" it was most definitely a spam attack. It caused 80000 unconfirmed txs, many of them legitimate.
With BIP 1xx, there is absolutely something that a motivated spammer could do - they could directly control the cap, moving it higher and higher. As I said previously though, that's not really what I worry about. I worry about the reverse. Miners can truncate blocks, and directly control how much other miners can include in their blocks. It allows crippling of the open-market transaction processing that we now have. Why abdicate this to the miners - a group that has previously advocated for smaller blocks with the stated rationale that it may force higher transaction fees? It is the fox guarding the henhouse.
And no, miners can't do this right now. Yes, they can control their own blocks, but all it takes is any one miner to allow those other transactions in with small/no fee. This is a check against the monopoly that could result from BIP 1xx.
BIP 1xx is union rules for miners. Those rogue miners who will process all your low-fee transactions? They could be branded scabs, and the union masters could shrink the block size so far that the transaction fees are forced higher regardless of the remaining miners.
While that is possible, you need to see it the way that miners see it and do some cost-benefit analysis.
Preventing transactions could cause several negative outcomes for miners. They would be losing out on transaction fees if a fee market doesn't develop. If the blocksize goes too low or fees go too high, people might just stop using Bitcoin causing the price to drop and thus miners are losing money. An increased backlog of transactions can negatively impact the full node by filling its mempool to the point that the node just crashes.
The only positive that could come out of causing small blocksizes would be the possibility of a fee market, which compared to the risks, is not something they would attempt with their already small profit margins
Also, if you think that miners would do this, then why are so many of them voting for 8 MB blocks?
A solution to this problem you present would be to create a lower bound on the blocksize limit. It would be that the maximum blocksize cannot go any lower than say 1 MB (or any other number you like).
The virtue is in the middle. And maybe for the future we can think of scaling solutions. Or even now! Who knows... But scaling has some visible flaws as seen on this thread