In most production distributed systems, there is an agreed upon common RPC protocol and a variety of ad-hoc messaging protocols. Often, this is HTTP for RPC coupled with a variety of job worker systems, maybe an "enterprise" message broker, and line-oriented protocol or two, and a few other custom services.
ZeroMQ isn't trying to replace unix sockets. Nor is it trying to be a panacea for distributed systems. It's trying to standardize a set of sound topology patterns with robust implementations over a common protocol. It's a damn useful tool for distributed systems. If you're system has everyone all chatting at once and saturating your links, that's not ZeroMQ's problem any more than it's unix sockets' problem.
The "cost" of a message operation is not fixed, and pathological operations are much more expensive by definition, so always selecting the least expensive operation that can be run at any point in time from the perspective of the node maximizes the aggregate throughput of the system. Of course, it also has the side effect of applying negative feedback to pathological positive feedback loops.
This is actually a mathematics consequence, so there are limited workarounds. Nor is it intuitive. Making parts of the system slower, with no other changes, can increase the aggregate throughput of the distributed system. For non-trivial distributed systems, you are unlikely to produce a robustly optimal design by accident.
Sorta. People say "distributed system" to mean a single, logical system - typically an application, or maybe some middleware that executes applications - that runs on many machines. So, yes, a distributed system will have bits moving over the network. But the point that jandrewrogers is making is that in a distributed system, the network connections are often dependent on each other. That is, sending data on one connection will impact the sending of data on another connection.
When someone says "distributed systems," you're probably thinking of a client application talking to a server, and maybe that server talking to some backend. That's not what people mean when they use the term. They mean, in the large case, thousands of processes running across hundreds of hosts, and all of those processes may communicate with each other.
In the client-server-backend case, it's okay to assume that each of those connections are independent, and to reason about them as such. In the thousand-to-thousand case in a distributed system, it's often not okay to assume that each of those connections is independent.