We are already using AMQP (0.91) for quite broad number of IoT devices. Unfortunately, RabbitMQ turns to be the only commercially available broker that supports this protocol (AMQP 1.0 is a completely different one, no matter only the version had been changed). RabbitMQ proved to be quite heavy resource hog, especially in our use case where devices are using TLS connections with individual client SSL certificate (most likely related to Erlang’s own SSL implementation). Additionally, the performance does not scale well in cluster setups and simple operations on paper to bring down one of the nodes or add new one to the cluster often causes all sorts of havoc.
MQTT has an oversimplified, but still very flexible model of pub/sub. There is usually no persistence involved for messages (basically there are no explicit queues, only those internally organized to cope with clients disparity in speed of production/consumption). That means the transport is unreliable in its nature, but that is rarely needed in IoT device world. MQTT also supports the notion of last will message for each client, which makes it very easy to track device disconnections without any additional infrastructure.
Not lastly, there are multitude of open source and/or commercially supported products to choose from for the broker solution.