Other people already explained that there's a bootstrap problem which prohibits "just encrypt that section of the handshake".
But the two SNIs are because of GREASE particularly. They might be avoided if you didn't want to enable GREASE, but we definitely want GREASE.
The idea of GREASE is, whenever we might want to do something that's visible to third parties, we must sometimes do it anyway, at least as much as they can tell, so as to ensure they tolerate this when it happens so that when we did want it we can do it successfully.
For example GREASE extensions are just nonsense extensions you propose in a TLS connection today. Chrome does this. "Hey server, can you do BINGLE BONGLE?" and of course your server doesn't do BINGLE BONGLE because that's nonsense, but to a "Security device" which is "Inspecting TLS connections as part of our Next Generation Firewall Technology" it seems like maybe we want to do BINGLE BONGLE. How should it react? Well, it should do nothing because the specification is clear that if you don't understand what is said you should ignore it, but without GREASE we know in SSL, and TLS 1.0, TLS 1.1 and TLS 1.1 these devices would freak out for each new extension.
1.6GB of customer personal information in a CSV file POSTed to a competitor's Dropbox? Fine. Your web browser wanted to use NEW FEATURE? Alert! Attack detected - lock down the network, summon armed guards! So hence the invention of GREASE.
For ECH GREASE works by just always pretending we're doing ECH. If we want to talk to old-web-site.example we send an outer SNI of old-web-site.example and it doesn't matter what our inner SNI is, it can be random nonsense encrypted to nobody, because old-web-site don't use ECH anyway.
If we want to talk to ech-enabled-site.example our browser discovers oh, here's a key for ECH for ech-enabled-site.example and it says we should ask to talk to boring.example, so the browser encrypts the inner SNI of ech-enabled-site.example with the key, and provides an outer SNI of boring.example.
In both cases this looks the same to snoops, there's an outer SNI they can read and an inner SNI they can't read. Which is genuine? No way for them to know. But the server knows easily.
But the two SNIs are because of GREASE particularly. They might be avoided if you didn't want to enable GREASE, but we definitely want GREASE.
The idea of GREASE is, whenever we might want to do something that's visible to third parties, we must sometimes do it anyway, at least as much as they can tell, so as to ensure they tolerate this when it happens so that when we did want it we can do it successfully.
For example GREASE extensions are just nonsense extensions you propose in a TLS connection today. Chrome does this. "Hey server, can you do BINGLE BONGLE?" and of course your server doesn't do BINGLE BONGLE because that's nonsense, but to a "Security device" which is "Inspecting TLS connections as part of our Next Generation Firewall Technology" it seems like maybe we want to do BINGLE BONGLE. How should it react? Well, it should do nothing because the specification is clear that if you don't understand what is said you should ignore it, but without GREASE we know in SSL, and TLS 1.0, TLS 1.1 and TLS 1.1 these devices would freak out for each new extension.
1.6GB of customer personal information in a CSV file POSTed to a competitor's Dropbox? Fine. Your web browser wanted to use NEW FEATURE? Alert! Attack detected - lock down the network, summon armed guards! So hence the invention of GREASE.
For ECH GREASE works by just always pretending we're doing ECH. If we want to talk to old-web-site.example we send an outer SNI of old-web-site.example and it doesn't matter what our inner SNI is, it can be random nonsense encrypted to nobody, because old-web-site don't use ECH anyway.
If we want to talk to ech-enabled-site.example our browser discovers oh, here's a key for ECH for ech-enabled-site.example and it says we should ask to talk to boring.example, so the browser encrypts the inner SNI of ech-enabled-site.example with the key, and provides an outer SNI of boring.example.
In both cases this looks the same to snoops, there's an outer SNI they can read and an inner SNI they can't read. Which is genuine? No way for them to know. But the server knows easily.