Для чего "для этого"? В случае взаимодействия по HTTP существует три возможных исхода:
- какой-то вменяемый ответ
- ошибка
- таймаут (фактически ошибка, но после ее возникновения состояние системы становится непонятным)

асинхронное взаимодействие (в т.ч. использование очередей) в первую очередь направлено на борьбу с таймаутами, потому что компенсировать в коде таймауты довольно трудоемко, все остальное в духе "ну мы там можем количество подписчиков регулировать и тем самым куда-то масштабироваться" - это свойство асинхронного взаимодействия, а не jms, amqp и прочих стремных аббревиатур, единственное что здесь еще играет хоть какую-то существенную роль - это возможность персистентных соединений, а заявления в духе: вообще ни в какие ворота: вот CometD вполне себе работает через HTTP, вообщем не кафкой единой.

Ну так к чему это все... ACK в очередях предназначен для того, чтобы пометить что сообщение было как-то обработано, отправителю от этого ACK не тепло, ни холодно

ну очевидно: весь контекст сериализовывать, а потом рассказывать про low coupling

Давайте так: я уверен на 100%, что ACK - это фишка консумера, а не продюсера, если вы так уверены, что при ACK что-то прилетает продюсеру (интересен сам механизм доставки сообщений продюсеру, если он ничего не слушает ), то можете привести в подтверждение правоты либо ссылку на документацию, либо на реализацию.
исправляю:

в мессаджинге тоже возможно синхронное взаимодействие через жопу .

как я уже пояснял другому оратору ( 22197194 ) вы также не неправильно понимаете слово "работает": ваше "вероятно это кому то нужно" возникает когда горе-архитекторы впаривают заказчику без должной проработки откровенную дичь, а потом пытаются мужественно преодолевать трудности:
- в Spring Integration (в Apache Camel тоже) оно есть просто потому, что это реализация EIP
- в EIP эту модель взаимодействия описали просто потому что она существует в JMS
- в JMS она появилась потому что на момент создания спецификации существовали вендорские реализации с поддержкой функциональности:Java™ Message ServiceJMS provides the JMSReplyTo message header field for specifying the
Destination where a reply to a message should be sent. The JMSCorrelationID
header field of the reply can be used to reference the original request. See
Section 3.4, “Message Header Fields” for more information.

In addition, JMS provides a facility for creating temporary queues and topics
that can be used as a unique destination for replies.

There are many styles of request/reply supported by enterprise messaging
products. From simple ‘one message request yields a one message reply’ to
‘one message request yields streams of messages from multiple respondents’.
Rather than architect a specific JMS request/reply abstraction, JMS provides
the basic facilities on which many can be built.

For convenience, JMS defines request/reply helper classes (classes written
using JMS) for both the PTP and Pub/Sub domains that implement a basic
form of request/reply. JMS providers and clients may provide more specialized
implementations. - а в вендорских реализациях оно было потому что иначе без этого невозможно было впарить клиенту

только какое отношение request/reply имеет к микросервисам? Адепты микросервисов топят за некий призрачный loose coupling, и при этом втихую реализуют RPC через жопу и умалчивают что это не что иное как temporal coupling, нарушая свои же собственные парадигмы. Зачем все это? У меня короткие идемпотентные запросы, результат которых нужен сейчас, а не когда кто-то там решит его обработать.

Ну просвящайтесь чтоли:
Messaging shouldn’t be used for queries
Messaging anti-patterns in event-driven architecture
When is an event not an event?

Ну вы определитесь кто на ком стоял: request/reply - это фишка JMS, которая прямо в спецификации описана, если мы принимаем за истину, что JMS проектировали умные люди, то посмотрев на кафку, мы заметим, что там "в коробке" этого нет , исходя из этого можно предположить что кафку писали бомжи... или таки просто не стоит предлагать использовать неподходящий паттерн там где это не нужно?