I'm sure SNI is next on the list, it will just take a bit longer. Until then, let's harden other parts of the infrastructure.
If I'm in a city square and I want to tell Bob something, but I refuse to let anybody know that I want to communicate with Bob, it's hard to see what I can do. Bob has no way to know I'm even trying to contact him, so he can't help.
That's not the problem though. You're not trying to stop an eavesdropper knowing you're communicating with a particular server, but rather which hostname you're talking to them as.
To extend the Bob analogy; you're not trying to hide that you're communicating with Bob, but that you're speaking to each other as members of Fight Club.
It's certainly not impossible, although overcoming issues of scaling or increased handshake round trips is a difficulty.
In order to be sure we're talking to Bob, so that it's OK if Bob knows we want his Fight Club certificate, I think we have to incur an extra round trip while we obtain the proof he's Bob and send back the request for Fight Club.
If we try to skip that step, Mallory simply interposes, we send our message to Mallory, believing she is Bob, and she reads it to determine we want Fight Club, we are undone. So we have to wait until Bob proves his identity, and only then reveal that we wanted Fight Club.
Of course, this approach would require the DNS record is authenticated, so DNSSEC is a must, added to which the DNS resolution must be encrypted, so DNS over HTTPS, DNSCurve, etc.
Two small problems I will mention, one of which I'm sure you already know: First, encrypted DNS and DNSSEC are not yet widely deployed, so this isn't the silver bullet many people expected of Encrypted SNI.
Second, for an endpoint which has many unrelated names and certificates - which is the case where encrypted SNI is gaining us a clear security benefit given our packets must have a plaintext IP destination - now they need to try every possible private key to see if they can open our encrypted SNI. This might be a very considerable burden.
The idea was to have a single common introductory keypair which all tenants publish to their DNS, in order to encrypt the SNI. That way there is no need to try multiple private keys.
The lack of DNSSEC deployment is an issue, although there's nothing to stop such schemes being employed on an opportunistic basis. However, when DNSSEC is available for a domain, the scheme should be enforced to prevent a MITM attack.
You can tell a few people near you that "someone" wants to tell something to Bob and an answer from Bob. They tell people near them and so on, until it reaches Bob. He then answers and tells people near him, they tell those who told them and so on, until the answer is delivered back to you. And since no one can hear what people tell each other, no one can assume that "someone" is you and not someone else talking to you in secrecy, many connections away from you.
Think overlay peer-to-peer networks.
But the minimum viable threat model is ISP appliances that do classification and identification of traffic, both passively and actively, like trying to probe for protocols and hostnames. If you are not targeting them, you are effectively doing nothing, but pretend privacy PR. Which is the case with Cloudflare's DNS.
Sure, scaling is harder, but it's not impossible.
If you decide well that's OK, we can do something simpler - everybody will have an infinite set of aliases like "Zanizabo" or "Fylnatis" but they won't be one-to-one shared secrets, alas Mallory simply hears you say "Zanizabo" and she says "Hey, Zanizabo, call Oxymoron" (Oxymoron is an alias Mallory has chosen for this purpose) and soon discovers that Bob answers so now she knows who you wanted to talk to.
Create a key out of nowhere for 2 parties to boot strap communicate safely. (obviously Diffie-Hellman doesn't solve all problems like knowing who you are actually talking to)
It still means that your ISP or a wiretap on your own internet pipe can check your browsing activity by monitoring SNI's, but then again, they can also figure that out for a lot of sites by just checking the IP.
Then you could argue that all sites should use CDNs to hide this, but then you open the argument of whether the internet should be centralized or decentralized.
Encrypted SNI would be nice, but are tricky (wouldn't work well in multi-tenant setups), and those that can sniff the SNI probably know where you were going anyway.
TLS 1.3 also encrypts the server certificate. So if you want to send bonus SNI but get back real certificates that's just a matter between client and server.
The use case for Encrypted SNI remains sketchy. If I am the secret police of some authoritarian nation, who would block diebartdie.example why wouldn't I instead block the IP addresses of servers offering diebartdie.example? Only because it causes collateral damage? But why do I care, teach them not to associate with my enemies.
Because the collateral damage may not be worth it. The website a handful of dissidents use may not be worth blocking everything running on Cloudflare for all your citizens, for instance.
For the DNS, the specification for DNS over TLS is almost trivial. DNS over HTTPS is a bit more tricky because their are more possibilities, interactions with HTTPS, etc. But still not very hard from a protocol point of view.
Operationally, DNS over TLS/HTTPS is mostly unknown. So it will take quite a bit of time before it is well know how to actually run that as a service at scale.
Encrypting the SNI in TLS is mostly the other way around. Fixing that has significant impact on the protocol.
There is no point in making very complex changes in TLS, which is already a tricky protocol without the DNS community committing to provide DNS over TLS/HTTPS at scale.
At the same time, securing traffic between a DNS stub resolver and the recursive resolver prevents are lot of middle box issues (but also creates a completely new set of issues). So it is worth deploying the even if TLS still leaks the SNI.
For TLS, the threat model is relatively simple: only an on path attacker has access to a plaintext SNI. In the context of route hijacks, 'on path' is not as simple as it sounds, but route hijacks are relatively rare.
For DNS the situation is much more complex. You have to consider not only traffic between stub resolver and recursive resolver, but also between recursive resolver and the various auth. resolvers.
At the end of the day, you need to consider all places where information is leaked and whether you want to do something about that or not. And in that sense DNS is independent from TLS.