ci.myorg-int.com -> 10.11.12.13
One advantage of such method is that it is possible to re-use the public CA infrastructure to provision services with TLS certificated. It also means that services can easily be migrated to public IPs once they are secured on the endpoint.The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration.
Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.
Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.
This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously.
DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.
I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor.
Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.
I think you underestimate the number of things on your network that run unconfigurable web servers.