Aleks Niches,

А что вам по этому поводу говорит официальная документация GoldenGate?

И что же говорит этот официальный документ?

Влияние на производительность - через повышенный размер генерируемого REDO-потока.
Т.е. если Ваша система оперирует только insert и select, то влияния практически не будет.
Если существенная часть нагрузки - update отдельных полей в таблицах с длинной записью - то влияние будет весьма существенным.
В том числе на процедуры резервного копирования/восстановления, на standby.

Повышенный размер REDO повлияет и на сам GG в виде роста объемов trail-файлов, сетевого трафика и, как следствие, на работу репликатов.

Весь вопрос - для зачем вообще требуется включать такой режим на уровне БД.
Для обычной репликации GG этого не требуется - необходимо и достаточно включить identifying key logging на отдельных таблицах, подлежащих репликации GG.
Режима IKL недостаточно при очень специфических условиях репликации - например, если на реплике исходная запись может быть удалена как следствие ILM.
Но даже в этом случае решения по реинкарнации утраченной записи могут быть иными, нежели чем SUPPLEMENTAL LOG DATA (ALL) на уровне БД.
К примеру, в одном из проектов при неудаче обновления -1403 (относительно редких, но измеряемых десятками-сотнями тысяч за сутки) сохраняли PK в exception-table, чтобы вытянуть недостающие записи непосредственно из источника - это было сильно дешевле supplemental log all на поток данных "проблемных" таблиц (не говоря уже о всей БД).