That's a part of software engineering though.
Once you reach a certain scale, you have to decompose your problems into subproblems. You solve those and assemble them into the final system.
The people making AMQP (following the original author's example and line of reasoning) were solving too many problems: they had a message queue, they had a wire protocol, they had service discovery, etc. This is all fine.
The author and others went on to make ZeroMQ with the intention of focusing on the communication between nodes and various communication patterns (pub/sub, reply/respond, etc.). They had some work on what should go over the wire but not too much, and they didn't expose things like authentication or discovery of services. Why? Because those are critical to applications, but not to a distilled, core message queue.
Using ZeroMQ, now, you can build up to what AMQP wanted to be. You can agree between your customers that ZMQ will be how you coordinate between systems, but you define your own message format using a separate standard. That standard is now independent of the wire protocol as well. Take something like ASN.1 or protocol buffers and define your message schema using those.
You want discovery? You agree on how services should be announced (a schema in ASN.1) and where the service registry should live (this would be a system configuration detail, where you specify where your system looks for a registry, maybe even federate registries). But this doesn't redo the work of ZMQ or the work of the serialization/deserialization format defined above.
You want to handle authentication? You pick your desired authentication protocol (public/private keypairs for identity, a capabilities based system, access tokens, whatever) and you again define a schema, define where the authentication service is located (or how it's identified in the registry above) and continue.
We don't reinvent TCP every time we want a new network protocol (well, some people do). Why would you reinvent the message queue when its already been distilled to a basic and fundamental framework that can be used to implement your desired business logic (now, if the MQ lacks some features that are basic or primitive, then it should be extended because it's not complete).
