The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being the sole exception). There also is no good way for enterprises to centrally manage these settings. DNS is a major source of information when doing threat hunting on a network and having that go dark is a big problem.

Enterprises aside, there has been a rise of people using solutions like pi-hole in their home networks to filter out traffic not just for ads, but known malicious domains, and telemetry trackers (which Apple does get filtered by, only calling them out specifically because they have an active interest in not being filtered like this).

Yes I think it's also a problem that ISPs are snooping and selling this information, but I think that is a less severe problem than rampant malware infections and the excessive collection of online usage data in the telemetry systems present in every webapp, OS, mobile, or IoT device. This increases privacy in one place, while making it much harder to actively protect yourself from the more aggressive and invasive sources of data collection.

Applications still have fallback though, right?

If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?

Think out of the box: Just don't let the app connect to an IP it has not resolved a domain name for.

That's what we can do with the Portmaster (https://github.com/safing/portmaster). Check it out!