Message queue is a single point of failure
I would really say the opposite. When you plan for production, your message queue will need to support somne sort of clustering for dealing with failure.
For instance (because AMQP was mentioned) RabbitMQ offers tons of knobs to control your durability/replication vs performance, and it’s one of the most stable pieces of infrastructure I ever had to maintain in production. But others solutions (MQTT, Kafka, ...) are there really to give you a durable and resilient central bus.
In my opinion though, I would consider messages bugs (or distributed logs) in a separate category than RPC or transaction-based things like REST. Message queues are really interesting when you want to decouple the load or parallelize task (you can build really awesome topologies with Rabbit or Kafk), to make the public-facing (with many definitions of public) endpoints as lightweight as possible, and smooth out and parallelize the work at the other end with workers.
What I mean is that both have strengths, and should be used depending on the context. And as your platform grows, it might make sense at some point to use more than one paradigm.