A good way to think about it is "email for applications". Email is a convenient asynchronous way for two people to talk, and (with a bit of formalization) it can be a good way for two or more processes to talk. "Email" here usually means a formal XML message with a standard header and app-defined body.

For example, a process can do part of a job, and pass it along to a mailbox. Another process can (perhaps later, or on a different machine) pick up work from this mailbox and finish it. This can hide the network topology (although in practice, that's not really so true) and also makes it easier to manage because you can take down or restart systems without losing work.

Messaging systems like Apache / Red Hat's qpid are getting very advanced, for example offering guaranteed latency, guarantees against loss of messages, and multiple ways to set up communications. You can set it up so one process "publishes" data while other processes "subscribe" to that feed of data. You can have 1-N, N-1 and N-M mailboxes. You can have edge-triggered or level-triggered data in some message systems.

In the majority of messaging systems, you have a process known as the "broker" which runs on all/most machines, and basically acts as the mailbox, persistent storage and router. It's kind of like sendmail on steroids.

Zero MQ is unusual because there is no broker, and it acts more like an advanced sockets library. There are reasons why this is both good and bad compared to ordinary broker systems.