First of all, operating a cluster is a hassle, sometimes (for no apparent reason) on of the members gets thrown out and doesn't automatically rejoin, you have to do that manually.

Second, and this is a bigger issue: If you use a query/response pattern, the requester typically creates a temporary queue for responses, with names generated by RabbitMQ. Those response queues are only readable for the connection that created them, so even if you were to replicate those queues and messages through the cluster, that wouldn't help anybody. BUT, the service sending the response needs to know on which cluster node the response queue, and use the connection to the right node to send the answer.

(At least this is my understanding; we had an application running on a single rabbitmq node, and when trying it on a cluster, clients wouldn't get responses; maybe the reason was something else, but the fact stands that it simply didn't work).

Such response queues are also not durable, they don't survive the failure of a node.

I assume it's possible to make applications work reliably with a RabbitMQ cluster, but I guess that would need to one of the stated goals upfront. Our attempts to retrofit applications to a cluster failed.