I like the efficiency, but moreover I like low latency and highly observable solutions, perhaps because my first and most formative job was building hard-real-t

I like the efficiency, but moreover I like low latency and highly observable solutions, perhaps because my first and most formative job was building hard-real-time interactive devices and this left me with a lifelong distaste for any system that responds more slowly than 100ms. Proxies inevitably introduce the latency of buffering, and this tends to go exponential to the point of timeout beyond 99%ile. Not saying network protocols don’t suffer at their limit too, but it’s more graceful and more directly instrumented. Neither are particularly straightforward to reason about, but ordering guarantees (in the Lamport sense) are (in my experience) harder to ensure at regional scale with proxies and service meshes. There’s a counterexample, of course: at intercontinental and interplanetary scale we lack the ability to stabilise tree topologies with predictable forwarding latency and are forced to use service proxies and bounded timestamps on replicated data to achieve ordering guarantees instead, of which the best known example is possibly TrueTime. This trades interactivity for scale. Multicast is definitely not easier to program for, and although I could attribute that to a shortage of high-level libraries, in practice the shortfall is mediated by the infrastructure dependency. This places it beyond the radar of most system designers in commercial environments, thus completing the elements of a downward popularity spiral. It’s a shame, but that’s tech.