While you might consider zmq a "known thing," and indeed it is widely used in a number of distributed systems, it's insufficient to say, "use zmq." zmq specifies only the transport part of the system (how sockets are handled), saying nothing about discovery (how participants find each other) or serialization (how data is encoded on the wire). Adding those features isn't impossible, or even necessarily that difficult. You could, for example, combine zmq for transport with protobuf for serialization and UDP multicast for discovery [*]. zmq doesn't support unreliable transport, so you'd also need to add your own solution there (e.g., managing UDP sockets manually). Still, it's all doable.
The problem is not in the effort required to build that system. It's that you then have to define, document, and defend your custom combination of techniques and protocols. When it comes time to convince someone to rely on it, you have to make the argument that your bespoke system is reliable, robust, free of nasty corner cases, and ready to be used in serious domains, whether that's a classroom full of undergrads, a government-funded R&D program, or a commercial product.
That argument can be made and won; after all, ROS today is a custom system combining various protocols and techniques (TCP, UDP, XML/RPC, custom serialization, discovery via a central master, etc.), and yet it is widely used and there are many ROS-based products and services in the marketplace. But there are many, many more current and future robotics applications where ROS will *not* be chosen, in large part because of its bespoke nature.
At OSRF, we looked carefully at this issue, considered a wide variety of options, and came to the conclusion that while we could build on things like zmq, we would really be defining and building another custom middleware. And things would just get more custom as we want to add features like quality-of-service (QoS). Do you want to support store-and-forward of messages? Priority among messages? Limited-duration delivery retry? Well, you have to invent your own rules for handling those cases, in addition to writing (and testing and debugging) the code to implement them.
By contrast, DDS (and its underlying wire protocol, RTPS) is an open, end-to-end middleware specification that is relied upon for serious applications in labs and industries around the world. And the specification includes extensive QoS settings that give you essentially any kind of behavior between UDP fire-and-forget and TCP retry-forever. That's exactly what we need for robotics applications. And there are multiple well-tested implementations of the specification.
DDS is by no means perfect, but we believe that it's the best foundation for ROS 2.
brian.
[*] We're intimately familiar with this approach, as we've done exactly that in the ignition-transport library, which is being used for communication within Gazebo:
http://ignitionrobotics.org/libraries/transport. It works great for its intended use case, but it has the drawbacks inherent to any custom middleware solution, described above.