When TLS, cookies or same origin policy are not a concern, why not resolve resource domains on the server side and output for example <img src="hxxp://10.0.0.1/picture.jpg"> to avoid that extra client side DNS request completely?
An often overlooked reason for supporting this is to pre-resolve hostnames behind a redirect. If you have a "http://a.com/resource, which redirects to "http://b.com/resource, and you know this relationship while you're generating the page, then injecting a dns-prefetch link can help hide the cost of the extra DNS lookup when the browser is following the 3xx.
EDIT: This is one of the things that a website I developed tests for: https://emailprivacytester.com/
GET /picture.jpg HTTP/1.1
Host: host.sample.com
[Other header: value]...
That could of course be solved with something like
<img src="hxxp://host.sample.com/picture.jpg" ip="10.0.0.1">
or even
<img src="hxxp://10.0.0.1/picture.jpg" host="host.sample.com">Out of curiosity: do you do (or know someone who does) this?
Do you think the functionality is worth the code to implement it?
No idea if it's worth it. Measure. Build a test case that implements a limited version or emulates this somehow. Test it against some group for a few weeks or months. Did it benefit you, made no difference or harm your goals? Did it give you something unexpected that you can turn into your benefit?
That being said, both can be worked around by other ways. You definitely lose a way to do geographical load-balancing, though (like in a CDN).
You could still implement crude geographical load-balancing by simply looking at client IP address for example at your load balancer/reverse proxy or the HTML serving server itself.
Nothing forces you to serve same IP address to each client. For media streaming, you can do some IP round robining to balance load. For serving CSS, images, scripts, etc. you'd want to hash some relatively static client derived attribute to pick a server to avoid defeating client side caching.
At its simplest, map first octet of client IP to optimal geographical load-balancing IP(s). I'm sure there'd be some sub-optimal choices, but it'd still be a reasonably good approximation. This works, because first octet determines at least whether a given IP is assigned to RIPE, ARIN, APNIC, specific organization, etc. You get about country level accuracy, at worst about continent.
Or use a full fledged geo IP database to find an optimal server IP for each client IP.
Of course this isn't very practical, because requires more maintenance and is not effortless like using traditional CDN DNS resolution based methods. Maybe some CDN vendor could offer this in a more managed, easily integrable fashion.
I'm sure it could be made work, if the potential latency win is worth the effort for you...