Respectfully, this is quite a one dimensional argument. The dynamics of the mempool are more nuanced.
Instead of a binary approach ie "if bitcoin succeeds ... then ... " or "if bitcoin fails ... then ...". These become self fulfilling tropes.
I would rather look at the mempool in 3 parts:
1. High value transactions. These are relatively price insensitive. And can afford higher fees, in general. These are the tx that will always contribute to the security budget, which is protection against (deep) reorgs. Important to realize that as the block subsidy decreases, the sensitivity to fees will become more important. This can be governed by the Nash Equilibrium where miners charge a bit more for priority transit of large tx, and large tx are willing to pay to get in a block.
2. Low value transactions. These are the tx that are crowded out, the poorest in the world, national currencies, hobby developers, and importantly, anyone wanting to use higher layers to scale bitcoin. While higher layers do scale bitcoin through batching, they normally require at least one transaction to set up, and one to tear down. High fees limit the emergence of higher layers.
3. Then there is the middle layer which crowd out the lower layers. This can be busy traffic, it can be spam, putting images and raw data in the chain, it can be gambling or it can be an attack to disrupt bitcoin. Normally an adversarial thinking mindset will consider the disruptive elements, rather than, assume good faith.
From a more nuanced position you can start to make design desicions and have a reasoned debate.
Syncing the chain on a mid tier laptop is a bit of a nightmare, especially when you are syncing from 2023->2024 it starts to get really slow. Increasing the block size would make that even worse. So any changes to the chain to improve the overall state of the mempool would need to be balanced with decentralization requirements, and the state of current hardware.
But the first thing is to see that there is indeed an engineering problem.
https://m.primal.net/IcHj.png