That blog posting is a little out of date. My comments are from a Mosquitto perspective but most of what I’m going to say is part of the MQTT spec so should be universal.
Indeed MQTT does not support message queueing (i.e. one-to-one communications) but you typically don’t do one-to-one communication in an home automation context. Instead something that has data publishes it and any client who may care about that data can subscribe to it. You can fake one-to-one through access control lists (ACLs) (i.e. only allow two clients to access a given topic). So there is a workaround to this limitation of MQTT.
In reference to queueing messages for guaranteed delivery and guaranteed order of delivery, MQTT supports that too, but that isn’t what the author of that article is referring to when he says “supports message queueing”. It is an unfortunate overloading of the term.
MQTT also has some pretty good security built into it including ACLs, encrypted traffic (TLS), client authentication, etc. I will agree that most AQMP servers like IBM MQ, Oracle’s WebLogic (I think they support AMQP now) and RabbitMQ will support things like client authentication and authorization on a more “enterprise” scale (e.g. hook into a company’s PKI and/or Directory Services). But in a home automation scenario a simple user/password file and perhaps some self-signed certificates for TLS is all the average HA user is going to want (who wants to set up their own PKI, yuck).
To address his points directly:
restrict access to queues
So can MQTT through access control lists.
manage their depth
MQTT (at least Mosquitto) has a max_queued_messages, though it is a global setting, not on a per-topic basis
and more
It is hard to compare that statement.
Ignoring the comparison between AMQP and MQTT, if you can find some devices, service, or APIs that require AMQP which would be beneficial in a home automation context I will wholeheartedly agree with you and perhaps even help with the implementation (messaging is one of my areas of expertise). However, without a concrete use case I just don’t see the value of adding a new binding to support a messaging protocol that no one uses in a home automation context.
Besides, as @steve1 mentions, if you use RabbitMQ you can bridge between AMQP and MQTT there and let OH stick to MQTT.
And for the record, all my discussion above also applies to JMS, and IBM MQ.