But I have not seen any adoption of QUIC either in clients or servers, outside the Google's circle.
Theoretically it could be possible to encrypt it (using DHE) before server validation occurs (i.e. before the server's RSA certificate is needed). However, it would rigorously change the protocol and I can imagine it would make some load balancing applications a lot more complicated as well.
Also SNI needs to match the hostname specified in the X.509 part of the cert. Certs are issued based on DNS names which need to correspond to SNI.
I'm not sure how much hiding the SNI would get you in terms of privacy. You could always just look at the destination IP address of the packet.
Destination IP will be the same for all sites on the server, SNI tells you exactly which site was asked for. Not meaning to be pedantic, sometimes the distinction isn't clear.
But in order to encrypt the SNI name, you'd first need to verify a certificate tied to a bare IP address. You'd also need to trust DNS completely. RTT would inflate significantly.
The CA system is a mess, but DNS is worse. Tying certs to bare IPs would create a deployment nightmare as well.
SNI is imperfect, but it is a big improvement over the previous status quo, which was single-IP per https host, which obviously did nothing to obscure the site hostname either.
For CDN services like cloudflare I'd imagine that it would make more of an impact, since in that case an IP address could potentially match many host names. Of course that has its own downsides - most notably the fact that you'd need to trust them with the server's private key.
For the 1rtt case, the request isn't sent till the TLS connection has been established. The attackers would have to keep track of these TLS connections, so this doesn't seem like a DoS vector.
For 0rtt the attackers might not need to keep track of state, allowing them to simply send TLS 1.3 requests, and overload the server's memory. My question is whether this is a legitimate concern.
