I would argue that the original way to do this--where applications used the system resolver--gave you that option, as the system resolver could trivially be modified to do whatever you wanted (well, unless you are on iOS; on iOS you are effectively just screwed, because Apple wants to control the entire software experience... more on this in a later paragraph <- edit: and also, I realized you can also do this on iOS!). glibc, for example, allows you to just give it arbitrary software plugins to implement the resolver, and so you--the person who configures your computer--have complete control over not just "who" you want to trust, but exactly "how" you trust them: you can decide to talk to Google, Cloudflare, or your ISP, and you can use DNS over HTTPS, DNS over TLS, unencrypted DNS, or something insane like Active Directory for all anyone cared.

However, at some point, web browsers decided that they didn't like end users being able to have this control, as, in practice, no one ever took advantage of it and they always allowed the operating system to select, by default, "use unencrypted DNS to the current ISP", which was slow, insecure, and often just wrong (as ISPs--for at least four reasons I can think of, all but maybe one of which I will assert are "bad"--would sometimes return incorrect answers on purpose); and so, now, the new reality is that software is coming with embedded DNS resolvers that do exactly and only what the software developer wanted (which, in a world of not just codesigning but notarization, increasingly means the user has no ability to have any say in the matter what-so-ever), because "developers know better than everyone else" (originally, this was just for performance reasons or to avoid strange behavior from ISPs, reimplementing the logic, but not the protocol, though now they are using that control to take it further).

For clarity, I will restate "the premise": if software uses the system resolver (the one that people erroneously like to claim is somehow synonymous with "unencrypted DNS to your ISP"), anyone who wants to use DNS over HTTPS can, AFAIK on any non-iOS operating system (if nothing else, by simply setting their DNS server to 127.0.0.1, if for some reason you can't just plug in your own resolver backend; edit: oh, actually, even on iOS, by using a local Network Extension, which is how Cloudflare's 1.1.1.1 app works), do that for not just their web browser but for all software on their entire system at once; and, when some new protocol comes out that is even better than DNS over HTTPS (maybe by solving some latency issue, or by using a decentralized resolver, or adding cryptographic verification), it would be equally easy to change your system resolver, and by extension all software on your entire computer, at once, to use that protocol.

And now, again, for clarity, I will restate "what happened": that this was deemed not something that either users or, interestingly, operating systems should be in control over (though it would be hilarious to see Apple try to fight this one out from their fortress of iOS, claiming you don't get to be in the App Store unless you use the system resolver, a similar battle to their issues with people doing HTTPS requests that don't use their App Transport Security library); and so, instead, software (possibly ever single piece of software you use: not just your web browser, but random desktop chat applications, e-mail clients, games... maybe even network-oriented command line tools such as curl!) will now embed their own DNS implementations, making it "your guess is as good as mine" as to what protocol or root of trust any specific piece of software is relying on :/.