It's important to understand the advantages of HTTPS via other protocols or custom crypto:
* HTTPS stacks are battle tested and there are multiple of them. Browsers in particular already ship a heavily maintained one that performs great, so using DNS on top of it gets all those benefits. Because there are multiple stacks the risk of people settling on a monoculture is a lot lower.
* People running a DNS resolver likely have the ability to run a good HTTPS server already, including having certs ready to go. Likewise, there are a bunch of battle tested httpd implementations out there and good https stacks to go with them.
* Proxies, reverse proxies, caching, etc are all well understood for HTTPS
* HTTPS2 has transport compression all figured out, so if you turn that on (which is 'free' once your server+client both support it) you're getting compression for free. HTTPS2 also supports multiple channels so if one request is pending you can still kick off another one over the same socket.
* Any debugging tools you can use with HTTPS can be used with DNS.
It's possible for a raw DNS protocol, or DNS+TLS, to pick up all of these benefits but DNS-over-HTTPS gets them almost entirely for free.
fwiw, web proxies over HTTPS2 are great too. The performance is great even over long distances because of the multiple channels and compression features.
You forgot the more pragmatic reason: middleboxes. HTTPS works everywhere, and introducing a new(2 years old) protocol (DNS over TLS) working on a new port (853) is a sure way to make sure it does not work in many places.
That mostly applies to corporate environments which already want to use their own resolvers anyway. For most people DNS over dTLS should work fine and if anything should be implemented on the OS level.
Your browser is not special, everything could benefit from secure DNS.
DNS over HTTPS is immune to amplification attacks.
If the alternative to DNS over HTTPS is a DNS-over-TLS resolver being run by a company without a website (???) then I guess that's easier than DNS-over-HTTPS. Are you really going to use a resolver run by a mysterious nobody?
There are probably more than a dozen HTTP stacks being widely used in production. It's not remotely a monoculture.
> Is there anything left, that's not on HTTP? Maybe NTP.
OpenNTPD also uses HTTPS (TLS, technically) by default [0].
Fortunately, they aren't yet trying to tunnel actual NTP packets over HTTP or anything like that, just using the information in the "Date: " header as a sanity check.
HTTPS gives you the packet ordering costs of TCP and the handshake costs of TLS.
With an SSH-like key setup - i.e. just getting the server's pubkey on first use and rolling it over when it advertises a new one - you could asymmetrically encrypt every request in a single UDP packet and thus gain the same security and lower 99'tile latency.
Putting everything, even lower-than-http level things on top of HTTP is a horrible idea, introducing yet another layer of abstraction.