This helps for SPDY (see T94896), and would also make more-efficient use of our cache hardware and simplify the overall structure and complexity of our production varnish config (puppet manifests, templates).
There are two basic approaches we could take for the transition, that I see on the surface:
1. Having prod applayer use host-relative URLs instead of proto-relative to bits.wm.o. Afterwards, we'd want to wait for various caches (ours and others) to expire out and for bits traffic to drop off to the bare minimum, announce that the hostname is going away (in case anything else custom references it, e.g. various tools), and then eventually decomission.
2. Move a variant of the bits-specific VCL code over to the text/mobile clusters so that it can handle bits traffic that comes in on the bits hostname and move the DNS for bits to alias text-lb. Then do the same applayer -> decom work as above (which also eventually gets mobile bits traffic onto itself instead of text-lb). It's an extra complex step up front, but it also means we can decom/reclaim the bits hardware earlier in the process (before traffic to the bits.wm.o hostname is killed).
After whichever path above (or something related - I haven't yet looked deeply at the issues with how the URLs are issued and rewritten today...), we'd eventually try to re-use the bits hardware in whichever of the text or upload clusters needs more load capacity the most. Their basic system config (cpu, mem, etc) is valuable for those clusters, but they'd need upgrades for SSD storage as well before joining.