So the point of this is to prevent Comcast from seeing your DNS queries. And then it works fine to trust the network to say "no, really, use this one and not the default DoH one" as long as that setting is one that Comcast would get in trouble for misusing. Notice that they don't return bad results for use-application-dns.net as it is.
What benefit is the additional complexity and overhead of HTTP buying you there?
> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.
When the DNS operator is your ISP, letting them block encrypted DNS is bad.
So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.
This would be a great argument if it was actually feasible, but then you have Chromecasts hard-coding Google's DoH servers to prevent ad blocking etc., and devices doing automatic firmware updates to change things like that after you've already bought them.
Pass the law that says the customer has to be given root and the ability to install custom firmware on any device they buy before saying that is reasonable.
You forgot the "let's intercept in a public place (e.g. public Wi-Fi hotspots)" one where blocking port 853 is super trivial while blocking port 443... is impossible. Sure, Google DNS will be blocked easily but there a lot of DoH providers!