Добрый день. Kafka и Jms для разных целей разрабатывались. Kafka это стриминговая логирующая система, ориентирована на пакетную обработку данных, что накладывает ограничения на гарантированную доставку и дедубликацию. Jms же ориентирован на гарантированную доставку отдельных сообщений. Да, можно реализовать для Kafka на стороне клиента функционал подобный jms, но тогда и производительность Kafka будет как у обычного брокера JMS. Jms позволяет писать более простой код и, например, не всякий разработчик сейчас сможет правильно написать код обработки ребалансировки консьюмеров Kafka так, чтобы сообщения не терялись и не было дублей. Ещё надо понимать, что под реализацией Jms тоже лежит БД, например, для ActiveMQ это обычно Kahadb, специально оптимизированная под обработку очередей и вряд ли БД общего назначения сможет конкурировать со специализированной БД по быстродействию.

Kafka даёт максимальную производительность (из-за которой её и используют ) в режиме автокоммитов оффсетов или редких ручных коммитов. Автокоммит, кстати, сконфигуирован в Kafka по дефолту в true. Видел проекты, где разработчики вешают аннотацию коньсьмера кафка на метод и вроде как получают сообщения и все у них работает, но упускают из виду дефолтный автокоммит, что может привести к ситуации, когда коммит оффсетов произошёл, а данные не загрузились в целевую систему, вот и потеря сообщений, причём даже в логах не найдёте информацию о потерях. При редких ручных коммитах чтобы не было потерь у нас должны быть огромные пачки сообщений обрабатываться за раз, что чревато ошибками и необходимостью переотправки. Про дубли - например после ребалансировки консьюмеров не удастся закоммитить оффсеты в той же сессии, при попытке коммита будет exception. Поэтому надо хранить оффсеты обработанных сообщений где-то ещё, во внешнем хранилище, обычно я в zookeer храню. Это только малая часть проблем. Вывод такой - Kafka имеет очень много особенностей эксплуатации, и если у вас в команде нет эксперта по ней, то легко нарветесь на какой нибудь мало понятный баг. Под Jms я имел ввиду именно спецификацию. Здесь все гораздо проще - есть спецификация, есть транзакции в Jms, и даже новичек сможет писать гарантированно работающий код. Конечно, в каждом конкретном случае, в зависимости от требований отказоустойчивости, нагрузки обдуманно выбирается то или иное решение jms, kafka, кэш или что то ещё. Зависит от кругозора архитектора. Про rabbitmq - мы принципиально не пользуемся им, т.к. он плохо горизонтально масштабируется и высока вероятность split brain кластера под нагрузкой, после которого кластер разваливается и лечится только полной очисткой данных.