Because it's encrypted to the app rather than the endpoint's OS or local DNS, so it's more difficult for the system owner to override it or implement a systemic policy.

The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.

And all that complexity is attack surface.

Not HTTPS. DNS over HTTPS.

If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.

If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.

By network operator I mean me, the person controlling my own local network.

Also: ISPs behave nice almost everywhere in the world where there is proper regulation.

What you have in the US is not a technical problem. It’s a regulatory one.

yup, hey i bought this device, that i cannot see what it is doing exactly. great.

Agreed. Many orgs will end up null routing the DoH resolver IP addresses. I warned them about this from the start of DoH development and they ignored me, since most end users won't block anything.