This sounds a lot like the argument we have already seen from the anti-"TLS everywhere" crowd. The claim is something like "If people start using HTTPS even for sites which [supposedly] don't need encryption, then governments will get annoyed at not being able to spy on people any more, so they'll finally force everyone to install a root CA cert that will be used to MitM their connections".
The logical extension of this line of thinking is that the tech community should never provide any extra security to anyone, in case somewhere some malicious actor is angered into retaliating against a certain group of users.
If you think that there are companies that rely on surveilling DNS requests (but don't already intercept and decrypt all their employee's web traffic) then you can campaign for browsers and OSes to have an option to turn off new security features like DNS-over-HTTPS/TLS and Encrypted SNI, but please don't demand that the whole internet go without these basic protections because of the internal policies of a few corporations.
My argument is not that the government will require root CAs for all clients due to a lack of surveillance options. My argument is that without the ability to enforce the law, the government may force a change that allows them to enforce the law.
The logical extension would not be "there should be no security features", and this is obvious, because the whole problem was not the existence of security features. The problem was the lack of ability to enforce policies, which organizations (companies, governments) are often required to do. I think the logical extension should be that security features should be developed with policy enforcement capabilities in mind.
Also, it's not logical to conflate this privacy feature with security features. Secure connections do not require SNI hiding at all. DNS-over-HTTPS is closer to a security feature, because without enabling DNSSEC, exploits are possible to the DNS which can impact non-TLS connections. That has a much easier workaround, which is to point DNS-over-HTTPS to a local provider.
> They'll probably issue an NSL to some cert vendor, or just tell the NSA to extract their keys, and then listen quietly to all secured connections.
There's no "quiet" in this approach. The cert vendors do not have the certificate's private keys; all the server operators send to the cert vendors is the certificate's public keys. Therefore, the only way to listen on the secured connections through a cert vendor is to use the cert vendor's private keys to sign a counterfeit certificate, which is presented to the browser. And at this point, the browser has everything it needs to prove that the cert vendor was compromised.
There are also several other gotchas: Certificate Transparency can force them to publish their counterfeit certificates to the whole world; Extended Validation is allowed only from some cert vendors (and requires Certificate Transparency); and last but not least, this (like all MITM) breaks client authentication (client certificates).
Finally, this only applies to cert vendors under the USA jurisdiction. A NSL has no power over other countries.
You're right, there's ways to detect it, though I don't think browsers today actually check the cert transparency log or CAA record when making requests. Without these two checks, valid certs created by a MITM tool using a CA's keys should pass without flagging any validation errors.
Even if most browsers don't check, it takes just one single person to expose the whole operation. This provides a strong incentive to use compromised cert vendors only for the most important operations, instead of indiscriminately against everyone: each use of a counterfeit certificate risks "burning" the whole cert vendor.
And as you say, browsers today might not check these things (and checking CAA doesn't make much sense for a browser, it's intended to be checked by certificate issuers). But future browsers, browsers customized with some third-party extensions, or non-browsers might check.
Chrome does check that all certs (at least [the ones issued after April 30][1]) are recorded in a Certificate Transparency log. Or rather, it checks that multiple logs have promised to include the certificate (via a signed certificate timestamp); the code that actually queries the CT monitors to verify that the certificate was included [isn't finished yet][2].
Browsers don't and can't check CAA records, because that's not how CAA is supposed to work. CAA is only enforced at the time of issuance. If you temporarily switch your CAA records to allow issuance for an hour, issue a cert, then switch them back to block all issuance from all CAs, the cert you issued remains valid.
The logical extension of this line of thinking is that the tech community should never provide any extra security to anyone, in case somewhere some malicious actor is angered into retaliating against a certain group of users.
If you think that there are companies that rely on surveilling DNS requests (but don't already intercept and decrypt all their employee's web traffic) then you can campaign for browsers and OSes to have an option to turn off new security features like DNS-over-HTTPS/TLS and Encrypted SNI, but please don't demand that the whole internet go without these basic protections because of the internal policies of a few corporations.