Финальная версия запроса работает хорошо и быстро.
Но не охватывает 2-3% записей, по которым операторы вносили данные некорректно.
Суть проблемы в том, что в журнале действий операторов фиксируются не все возможные варианты изменения группы клиента, возможны варианты задания/изменения группы, которые не фиксируются в журнале, такие как:
1. При создании нового клиента его группа нигде не фиксируется. Эту ситуацию я обрабатываю следующим образом: если после создания клиента его группа более не редактировалась, то в журнале записей не будет и можно полагать, что текущая группа клиента была задана при его создании; если же записи в журнале есть, то у первой записи будет OLD_VALUE.
2. При активации клиента для него задается группа и эта группа нигде не фиксируется. Тут я исхожу из допущения, что до активации все неактивированные клиенты находились в предопределенной группе, а после активации ситуация схожа с пунктом 1 (если записей в журнале нет, он был активирован с текущей группой, иначе в журнале нужно использовать OLD_VALUE).
Эти допущения покрывают более 95% случаев, но есть ситуации, когда операторы отходили от регламента и делали например так:
1. Клиент создан в предопределенной группе (группа0).
2. Клиента переместили в группу1.
3. С клиентом сделали некоторые операции.
4. Клиента переместили в группу2.
5. С клиентом сделали некоторые операции.
6. Клиента переместили в группу3.
7. Клиента активировали, при активации выбрали группу1.

В результате мой запрос считает, что клиент находится в группе3.
Просто отфильтровать записи в журнале, предшествующие активации, нельзя: клиент может быть не активирован и тогда нужно учитывать всю его историю, а если в критерии join добавлять что-то вроде and (log.MOMENT >= client.ACTIVATE_DATE or client.ACTIVATE_DATE is null), то очень серьезно падает производительность.

И тут я подумал, что возможно пора подумать о переборе в цикле.
Количество клиентов у меня не очень велико (сейчас порядка 10к, максимум будет 50к), зато я буду использовать императивный подход и не буду ограничен в логике обработки данных.
Или все же в SQL можно описать подобное условие без падения производительности?

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