This doesn't address why this needs to be built in to the browser when Android already does DoH by itself. I assume there's a reason, does anyone know what it is?
You may or may not think this is a better design (I was one of the people responsible for Firefox doing things this way, so I do), but hopefully this explains the difference.
See: https://educatedguesswork.org/posts/dns-security-dox/ for more on the difference.
That alone makes a native browser implementation a better solution than the OS version.
[0]: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the... is just one example I found on Google (in this case, using the C function getaddrinfo bypasses the tunnel entirely, which Chrome in particular uses for DNS queries - only android API calls respect the tunnel), but you hear about stuff like this every couple years; in that post they also link to a prior incident where connectivity checks and NTP updates were conveniently not using the VPN even when killswitches are active. Neither of these incidents have been fixed as of the time of writing (and Google explicitly doesn't consider conncheck/NTP calls occuring outside of the VPN tunnel to be a bug.)
Google has already shown to have a habit of not properly respecting privacy focused settings, and DoH is intended to be primarily privacy focused. (As it's used to prevent DNS tampering.)
In the OS you need to trust (1) the OS vendor, (2) the client vendor & (3) any VPN app or HTTP intermediary that's integrated with OS network APIs.
In the client you need only to trust the client vendor.
Granted, the os would need to read your address space, not simply supply a recording DNS API, but still...