Thank you, it's clearer now. From what I understand, messaging can also be useful as a way to simplify client/server communication in client-server architectures, correct?
For me, the radically interesting thing about messaging is that it's asynchronous. You send a message, and the message could be picked up and acted upon hours later (although usually it's more like milliseconds, or in pub/sub, it could be never).
This is unlike client-server, where basically you always sit waiting for a reply immediately.
However there are some people using messaging for client-server. Notably OpenStack is using RabbitMQ this way.
Another aspect to this is scaling: you might send a message to a mailbox, and on the other end [the sender doesn't know this] there could be a whole set of worker processes picking messages and working on them. Of course client-server can do that, but it requires changes to the client usually to make that happen.
On the subject of ZeroMQ: while broker systems (qpid, RabbitMQ, etc) might seem a bit "boring" and "old fashioned", there's a good reason for setting up mailboxes and persisting messages, particularly when you're trying to make scalable, safe architectures.
