Касательно 'Dual writes позволят эмитить уже "правильные" события сразу.', то

тут можно только ответить цитатой из классики - "Догнать Савранского - это утопия".
Есть сразу несколько измерений проблемы:
1) Концептуальное - о каких Event мы говорим? Если это "правильные" Event Source события, то надо сразу говорить и выделении границ Aggregate-ов , причем уже не в чистом поле бизнес домена а контексте существующего монолита - что само по себе уже есть проблема.
Если это же просто какой-то поток событий без выделения границ агрегатов, то все равно надо строить какой-то ACL на стороне что бы адаптировать его к ES архитектуре.
2) Архитектурное - порождается связность между монолитом и микросервисами, монолит уже знает о сервисах - и это беда ( известный антипаттерн, например здесь - https://www.slideshare.net/xpmatteo/strangler-application-patterns-and-antipatterns/35 )
3) Техническое - зачастую, данные об event не доступны сразу в одном месте, и собирать их надо по всему стеку вызовов транзакции монолита, где-то складировать, или дополнительно кверить в базу если чего-то не хватает, и сам event уже отправлять после коммита в базу - это не выглядит как задача для рядового прикладного программиста.
плюс, надо что-то делать с проблемой distributed transaction ( которые кафка, например, не поддерживает ).
плюс, правильно протестить все граничные условия.
4) Организационное - если функционал монолита распиливают срузу несколько команд ( например в нашем случае это до 10 команд в 4 разных локацих ), такая инструментация монолита может легко превратиться в отдельный ночной кошмар.
5) Практическоe - в правильно забодяженом монолите, заармированным парой-тройкой фреймворков и ORM-ов, это может быть практически нерешаемая задача в принципе - отловить все места где надо развесить "правильные" события.
6) Эстетическое - со стороны это все может выглядить как неловкая попытка украсить коричневого крепыша дурацким ожерельем из жемчуга (и полить ниной ричи).

Из своего опыта практического распила довольно объемного монолита, могу добавить что мы сразу пошли по-пути CDC и ни разу об этом не пожалели. У нас было несколько генераций - сначала захватывали hibernate envers log через стандартный jdbc connector, сейчас выкатываем более продвинутую систему которая захватывает непосредсвенно транзакционный лог на основных таблицах.
Далее уже на кафке пропускаем этот низкий уровень через stream processing и на выходе получаем стримы бизнес-событий. Все очень модульно и изолированно, если что-то надо расширить или добавить то это все происходит на стороне сервисов и никак не затрагивает монолит. Тут же можно добавлять фичи, такие как identity mapping например.
Коллеги из удаленных локаций пытались использавать dual write, несколько месяцев потрахались с этим, и в итоге перескочили на наш подход c CDC.

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

А можно немного ликбеза - что подразумевается под CDC ? Про dual writes из контекста понятно, а CDC - какая-то новая для меня аббревиатура.

А где именно распиливали монолит? Предметная область/компания