pull down to refresh

I have to step in and defend ETH2 a bit here.
Awesome! This is exactly what I was hoping for when I wrote it. Let's break everything down:
You are making the assumption that users would not withdraw their funds in advance of a UASF, or that trust-less solutions like rocket pool would not be utilized.
Yes, users would absolutely attempt to withdraw their ETH, however, keep in mind in my scenario (and I do admit I'm making some broad assumptions) the exchanges themselves are the attackers. They can impose long withdrawal times on ETH, citing any number of reasons (technical difficulties, third party custodian, etc.) in order to keep funds on the exchange. I could even go tinfoil hat and say this is where nation states will step in and begin to ban withdrawals to noncustodial wallets. Remember, exchanges are slaves to the governments they operate within.
As for decentralized solutions like a DAO, I think a majority of ETH users will still place their funds on centralized exchanges. We only need to visit rekt to see how pooling funds in a contract is a gigantic risk of a loss of funds entirely. These DAOs can say that they're trustless and whatever other marketing scheme they want to pull off, but ultimately someone has to be running, monitoring, and maintaining the validators.
Bitcoin network has dealt with numerous issues regarding centralized mining pools (and still does), and users have rallied when called upon. There's no reason to believe that the Ethereum community would not keep a close eye on their own consensus issues.
The main difference here is the validator set is pseudo-anonymous. Unlike mining pools, where you can actually see how much of a share of the hash power any pool has, you can't see how many validators an entity is running. So what will happen is the Ethereum community will have to make a retroactive change in response to an attack, instead of being able to proactively prevent it from happening in the first place. This is in-line with my previous post about PoW vs PoS because it's also proactive vs reactive security.
Even if staked Ethereum were to consolidate into a cartel of key players (which it will, no argument there), it would be similar to 51% control from a PoW cartel. There's a few attacks they can pull, but they can't forge signatures or rewrite history, or change consensus rules without triggering a hard fork. Plus validators must publicize on the beacon chain, where their consolidation will likely be tracked as time goes on (versus hash power hiding in complete secrecy).
Correct that they can't forge signatures or rewrite history, though technically they could rewrite history, there's just an automatic penalty for doing so, which means they won't bother. However, my scenario outlines how they could change consensus rules, even if that does trigger a hard fork, as it won't matter since they have the majority of the user funds. Validators have one field where they can customize their identity, called the graffiti. Here you can see the graffiti field's use for every new block. You'll notice a good number of blocks have this field blank, some are advertisements, some have client info, etc.
Both Infura and Etherscan are a weekend project to replace. Yes they are far, far over-leveraged and a huge centralization risk, but any betrayal of the network and both services would evaporate them overnight. Block explorers are dime a dozen.
I disagree here. We already know there are plenty of alternates to both Infura and Etherscan, yet they remain dominant due to network effects of everyone using them already, like Metamask, for example. Both Infura and Metamask are owned by Consensys, so it is unlikely that Metamask, which a majority of "Defi degens" use, will default to another provider. The real social aspect here is how the centralized exchanges can put the spin on their change to get the community to accept it. All they have to do is split the community and get some followers, then they can enforce their chain by excluding the minority fork.
Ethereum does have an issue of nodes being too cumbersome to operate. That should be a larger concern for Etherbros.
I think we're way past the point of no return here. There are some clients which use less resources, but since they're not as popular or as well funded as Geth, there's no telling how their developers will maintain the software.
I think that about covers everything you brought up. Thanks for starting some discussion on this!