Encrypting SNI would come at a cost
TLS 1.3 provides 1RTT encryption by having clients speculate that the server is modern. The client opens by saying "OK, I assume you know how to do this key exchange and here are my parameters". If the server actually does _not_ know the flavour of key exchange proposed, it sends a retry message, explaining what it does know instead and we're immediately paying an extra round trip cost.
SNI travels in that first message from the client, but if we are to encrypt it with the DH key we can't send it until the client knows that key, which means we again pay an extra round trip.
You might think hold on, surely we can immediately start our transaction because we have the encryption keys now, so we're not paying an extra round trip. Nope, we mustn't start the transaction until we've seen the server's certificate, so we have to wait an entire extra round trip.
The best option if we want to really encrypt SNI is to have servers able to choose to go early, so you'd connect without SNI, and then after finishing DH the server could choose to either immediately send certificates (so it can't serve different sites this way) or ask for the encrypted SNI first. This would mean it's 1RTT for www.google.com and 2RTT for another-cat-blog.example because the latter is on a cheap bulk host. That's... not great.
A way forward that's resistant to attack but isn't full encryption would be use of hashing, the client specifies only a hash of the hostname, not the plain name, and the server matches this against its known list of possible names. A snooper sees the hash, and can try to guess what it means, but if they have no idea they're out of luck.
We can make the snooper's life hard either in the protocol design itself (e.g. send password-style salted & pessimised hashes, so both the server and snoopers must recalculate for each connection) or in our naming (e.g. name the members only web site zqdm-48gb.example.com, not members.example.com) but this is far less comprehensive than full encryption.