Как же так... вы постоянно топили, что в очередях сообщения не просираются, а в REST какие-то невообразимые накладные расходы на транспорт, а тут выясняется, что если настроить очередь так, чтобы сообщения в очереди действительно не просирались, то накладные расходы в REST таковы, что нужно сделать каскад из 10 нжинксов, чтобы получить такой же throughput как у RabbitMQ, вот тут тоже эксперты по RabbitMQ выдают "рекомендации" :
- Use transient messages
- Split your queues over different cores
- Disable manual acks and publish confirms
- Avoid multiple nodes (HA)

Из всего прочитанного я сделал следующий вывод: у RabbitMQ есть два режима работы:
- терять сообщения, в этом случае оно хоть как-то к REST приближается, но из-за request/reply нужно все делить на 2
- тормозить

Если вам не нравятся результаты тестов, которые я привел, можете сделать свои, благо и там и там методика и исходный код опубликованы. Но есть мнение что особо не поможет, о том что в RabbitMQ наступают проблемы с latency при потоке в 30-40 тысяч сообщений в секунду, пишут даже на сайте RabbitMQ: https://www.rabbitmq.com/blog/2020/06/18/cluster-sizing-case-study-mirrored-queues-part-1/

Чет вы быстро выдохлись. Давайте лучше схему с request/reply с точки зрения производительности чуть более подробно разберем, а то есть мнение, что мое предположение о делении throughput на 2 было ошибочным...

вот мы подключаемся к RabbitMQ, я так полагаю что в приложении нужен некий пул этих персистентных соединений - мы же не хотим, чтобы это было медленно как в HTTP/1.0, но когда мы посылаем сообщение из определенного места в коде, у нас есть желание, чтобы ответ в это же место и пришел, поэтому мы должны создать временную очередь, в которую должен приходить ответ и которую слушать будем только мы. Эта очередь должна быть всегда уникальна и к соединению из пула ее ну никак привязывать нельзя, в противном случае на таймаутах другие вызовы будут получать наши ответы вместо своих, т.е. прежде чем послать сообщение в RabbitMQ мы должны дополнительно вызывать некий RPC, который в RabbitMQ создаст новую очередь (кстати, кто должен чистить старые?) - вам не кажется, что в этом месте появляются дополнительные расходы, соизмеримые с установлением соединения по HTTP?