Harder to snoop? You said it yourself, "[t]o most customers 90% of 'the internet' is the services from these [few] providers."
So we're making snooping by ISPs more difficult by using a technique that only works well precisely because so much of the modern internet is centralized behind a few hosting service providers.
Encrypted SNI will be at best a lateral move. Much time will be spent (especially by small-time providers and open source stack authors) trying to keep up with the privacy enhancements offered by the big hosting providers just so they can lay claim to the dubious benefit of enhanced privacy.
More likely, these enhancements will be leveraged to centralize hosting even further. The more complex the protocol stack, the more costly it is to avoid using centralized providers.
And much like with browser fingerprinting, whatever marginal benefits exist will be quickly erased once the existing tracking systems build and maintain databases that map IPs to likely sites. Nobody has even tried to demonstrate that this isn't feasible with aggregators--everybody just assumes it's not practical. And that ignores the reality that countries like China can force companies like Google, Apple, and others to host services domestically, making encrypted SNI of little value from day 1.
I absolutely oppose encrypted SNI because it adds significant complexity for little benefit over the long term. Worse, it will likely hasten centralization. A proper solution would be to fix TLS so SNI always happens over an encrypted channel. But as with TLS 1.3 0-RTT, in reality performance is allowed to trump security. That's the calculus of the very same organizations pushing encrypted SNI.[1]
As somebody who has written DNS, HTTP, MySQL, RTP, RTSP, SMTP, and even HTML parsing stacks from the ground-up, we need to focus on making these things simpler. We need to shift our efforts to writing implementations using specialized languages and techniques for software verification so we can write provably safe and correct implementations[2] rather than chasing feature after feature.
[1] In fairness, these organizations are diverse and if the encrypted SNI folks had their way they may also have come up with a better solution. But that doesn't justify encrypted SNI on its merits.
[2] Rust doesn't even begin to solve this. As ugly as buffer overflows are, when it comes to tracking and data exfiltration they're hardly the biggest culprit. And in any event Rust only solves a subset of overflows. Techniques for building circular-reference data structures in Rust (i.e. using indirection through array indexes--basically pointers to a specialized heap) can and _will_ result in similar issues. At the end up the day, for core infrastructure software no general purpose language suffices. For core infrastructure, there's no avoiding doing things the hard way. Core infrastructure software needs to be developed in the same way SQLite is developed, but that will never happen as long as these standards are moving targets that rely on many moving pieces.