Message queue functionality is something that is/was traditionally handled by a dedicated message broker, i.e. RabbitMQ when using AMQP as protocol.

A growing trend is to use solutions that are easier to setup and maintain, such as pub/sub solutions (quite many of them). There are also NoSQL databases that have added such extensions, and the most common example is Redis.

MongoDB could fit very well in this world. (Capped) collections with polling subscribers can already today be used to simulate a message queue, but this is just a workaround. Having native support for publish/subscribe in MongoDB (with blocking readers, for example) can be used to add message queues without having to setup and maintain separate solutions and keep the same concepts as the application developers have grown used to, like the rich expressiveness of documents as messages. The advantages of replica sets can be used to add reliability and durability of messages in a queue (well, this would rule out capped collections).

An API would have to be created, and the concepts would have to be defined.