Чет не пойму, стеб ли это или банальное невежество...

Трудности написать г.код нет никакой, однако есть определенный набор "проблем", которые нужно решить прежде чем этот г.код писать, проблемы примерно такие:
- определиться что же именно отправлять:
-- можно же слать просто ключи, чтобы потом те кто нужно за данными ходил
-- можно ввести понятие "события" (тут уже непонятно почему потребитель должен знать о событиях в моей системе и я буду должен поддерживать обратную совместимость)
-- можно отправлять raw-данные (или как-то преобразованные): тут опять получается что или я свои структуры наружу выставляю или нужно приседать с обратной совместимостью
-- можно слать вектора изменений: почти те же грабли что с raw-данными
-- можно слать команды: тут я уже от получателя начинаю зависеть
- определиться когда отправлять: здесь основная проблема с тем, что хотелось бы отправлять:
-- более-менее агрегированные изменения (например чтобы на insert+delete ничего в итоге не уходило)
-- зафиксированные изменения

Начиная решать перечисленные выше проблемы сразу сталкиваешься с другими:
- так или иначе какие-то сообщения могут быть или не отправлены вообще или отправлены несколько раз - тут ничего не поделать, жизнь такая
- появляются проблемы с зависимостью (явной или не явной) одного сообщения от другого, поэтому возникают грабли с очередностью отправки или получения

Вот если все эти трудности "героически решить", то выбор транспорта для отправки - это ну совсем несущественная мелочь, о чем, в принципе, тебе здесь два мембера и пытаются донести свою мысль: сам по себе MQ проблемы, перечисленные выше, никак не решает - он просто убирает зависимость успешности доставки сообщения от работоспособности получателя в конкретный момент времени, перенося эти риски на себя. В целом лично у меня складывается впечатление, что более-менее "безпроблемно" (т.е. в лоб) можно делать отправку из CQRS, но и то там так или иначе появляется паразитная связность между отправителем и получателем(ями), да и все равно нужно уметь бороться с недоступностью транспорта. Если же у вас не CQRS, а CRUD, то там все печально с точки зрения быстрого старта, вот если рассматривать ситуацию на примерах, вот что нашлось в гугле про тот же самый хибер:
- https://medium.com/swlh/harnessing-hibernate-events-for-data-change-detection-52981f4badf0 - смуглый парень считает хорошей идеей ловить insert/update и сразу слать это дело в кафку не дожидаясь фиксации транзакции (тут вроде был персонаж, поклонник кафки, который делал то же самое), ну а если код посмотреть на гитхабе, то у него почему-то даже синглетоны мутабельные
- https://vladmihalcea.com/hibernate-event-listeners/ - бледнолицый пишет лог в ту же БД, в которой происходят изменения, тормознуто, но зато надежно, правда потом непонятно каким образом этот лог разбирать

Если разговаривать про отпуск и забыть про факт, что сейчас в Австралии локдауны то тут то там, то могу сказать что машина машине рознь, особенно учитывая, что я люблю по всяким ибеням ездить, т.е. для путешествий на вменяемые расстояния я предпочту старенькую тойоту любой другой марке.

Что касается "топика про очереди в целом": учитывая то, как сейчас работает опенсорс, можно с уверенностью сказать, что из коробки вообще ничерта не работает, т.е. если связался с опенсорсом, то будь готов постоянно читать исходники и унижаться при попытке что-то отправить в апстрим, на фоне всего этого IBM MQ выглядит просто космолетом - всего-то нужно XA настроить и забыть навсегда, а опенсорсный пепелац нужно чинить всегда

в моем компьютерном магазине все просто: есть только две модели телефона (прошлогодняя и новая) в разных редакциях и две модели латопов Никакого деления на классы нет. То же самое с MQ: есть ПО которое просто работает ровно так как ожидается (можно хоть из сеттеров сообщения слать), а есть то, с котором должна постоянно пердолиться пачка пионеров.

Есть мнение, что слухи про тормознутость XA "слегка" преувеличены: ну пишет оно лог на диск (а куда еще писать-то, если кругом враги?), писать оно хочет надежно, поэтому логи нужно размещать в "хорошем" месте, а не где попало (точно не в докере ), но слухи-то ходят уже лет 20, а за столько времени у нас уже везде SSD появились, кроме этого 1PC-оптимизацию никто не отменял...

Вот нашел занимательное чтиво про XA

В целом вся эта история про "тормознутость" XA, редкую применимость и пр. исходит не из того, что XA действительно плохо, а из-за того, что:
- житуи окончательно умерло, а TM-таки был частью житуи
- чтобы сейчас наворотить примерно то же самое нужно довольно старательно поприседать

однако в далеком 2004 году про очереди писали ровно то же самое что и сейчас:
XAIt's fairly well known in the industry that some RDBMS' XA drivers are full of problems (*cough* Oracle *cough). What's worse, many major JMS implementations switch off disk forcing altogether by default. This makes them look really, really good on benchmarks, and makes you look really, really bad if Little Johnny pulls the plug on your JMS server at an inopportune moment

положительные сценарии совершенно ни о чем не говорят, попробуй, например, расписать "проверяет запрос, сверяется с текущим балансом пользователя" учитывая что пользователь в данный момент времени выполняет еще какие-то транзакции

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

угу, через минуту клиент уже точно решил, что ну его нахер этих дебилов, которые обработать запрос толком не могут.