DoH uses raw bytes for DNS answers and not json: https://www.rfc-editor.org/rfc/rfc8484#section-6
The idea behind it remains the same. HTTP/http2/http3 as a carrying mechanism for an existing binary format makes no sense when none of the benefits of the new format are actually coming from the HTTP protocol. This only increases the attack surface and complexity of the protocol. I don't know, maybe there's a benefit to setting cookies and language headers for DNS requests but I'm not seeing it. The only potential benefit touted in the RFC is that web applications can now do DNS lookups in a standardised way and I don't see how that's a benefit for anyone but user hostile companies.
Now we've reached the situation where HTTP/2 server push has been deprecated in almost all browsers but is still part of the DoH spec. I don't see the benefit of including server push support in the first place but because it's part of the standard we'll have to deal with potential servers relying on features disabled in libraries or unmaintained code in libraries that lays dormant because the major consumers of HTTP have stopped calling their methods.
And pretty much anyone can run a personal DoH stub resolver for ~$0: https://github.com/serverless-dns/zero
Just DoH won't save you from an oppressive government and neither will DoT. You can run DoT on port 443 and it'll appear as normal TLS traffic as well. Unless the state actors are doing extensive fingerprinting (that will expose DoH servers as well) I doubt it'll make a difference in situations where DoH makes sense. In areas where occasional government TLS MitM attacks are common, neither DoH nor DoT will protect you.
DNS over TCP is actually slower in many configurations, at least the ones I've tested. HTTP libraries and servers have been developed for fast opens with (probably protocol violating) workarounds for getting rid of the handshake in any way they can but DNS implementations seem to care very little, especially on the client side. 1-RTT TLS fixes serious connectivity annoyances while also providing security benefits at minimal overhead.
I personally prefer DoT over DoH, but the industry is moving away from DoT. Taking DNS, which is a fine protocol lacking encryption and sessions and adding encryption and settings is a very simple solution. An nginx stream proxy forwarding TLS traffic for port 853 to 53 is enough to set it up if you're not bothered by the handshake time that can be negligible in the age of 5G and fiber connections if you live in the right area.
Sadly, the "let's turn everything into JSON so I don't have to learn what bytes are" crowd won and becoming an old man yelling at the cloud doesn't solve anything. At least ODoH provides some additional benefits that just encrypting DNS doesn't at the cost of extra latency, though I'm disappointed with how its rollout is going.
Personally, I use DNS over UDP to my local PiHole which deals with all the secure DNS lookup protocols. This way only one device needs to maintain connections and deal with session resumption while every other device can rely on the simplicity and speed of UDP connections. Not exactly a defence-in-depth approach but it works well enough for me.
A real solution would be to meaningfully extend DNS in some way but doing so would require backporting this new protocol to at least ten years of computers, tablets, smartphones and IoT devices. I'd welcome a new protocol that fixes these issues if all I'd need is install another app or set up a forwarding service for legacy software, but most of the world wants something that Just Works(TM) and that Windows 7 server in the basement everybody hides when the auditor visits still needs to work.