Если все на одной железке крутится то сеть в последнюю очередь смотреть. Если на разных то стоит глянуть

Как минимум проще

Опять же с кэшем - идеально туда класть только то что не хочется инвалидировать. Тогда можно чейны юзать

И тогда есть шанс получить хоть какой-то Профит от кеширования результатов базы

Но лучше меньше кода грузить)

findBy([ 'id' => [16,21,23,19] ])

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

xhprof?

Но это APP_ENV=dev стандартный + opcache + preload

APP_ENV=prod самая медленная часть

$repo->perist($aggr1);
$repo2->persist($aggr2);
flush();

Вообще честно говоря непонятно почему у тебя сохранение нескольких агрегатов происходит в одной транзакции. Разве они смысл их не в том, чтобы они сохранялись в разных транзакциях?
Но самый главный вопрос, для твоего проекта это вообще актуально ?)
Просто у людей тут rc случаются. А у тебя есть такая проблема ?)
К слову Валентин тут тоже правильный вопрос задал, если это 2 раза в год случается, стоит ли игра свеч ?)
А про транзакции тебе Максим тоже дал подсказку, тут же смешаны данные авторизации/аутентификации и бизнесовые. Почему же они должны сохраняются в одной транзакции ?)

И очень легко убедиться, что произошло смешение, с помощью вопроса снова от Максима "происходит ли логин, по всем 3 полям ?"
(Чую что по Инн пользователи у тебя не логинятся ))

А оптимизации композерского автолоада применял?

Гидрация. Десериализация.

Не забывай ты в дев режиме - там много оверхэда. Тебе в прод режиме и без дебага надо чекать

Ну я скорее всего не допонимаю что до меня хотят донести.
Вот есть регистрация. 1 форма, пользователь сразу вводит много данных, среди них ИНН, Емейл и телефон. Все должно быть уникально. Rc нет, но как говорят сам подход с предварительным select - не айс.
1) Если один агрегат - говорят, что скорее всего я  мешаю много данных, ок. Делаем два. Агрегат "аккаунт", агрегат "Персональные данные".
2) Но 2 Агрегата надо атомарно сохранить.  Если не в одной транзакции, то есть вариант, что аккаунт сохранится а ИНН в отдельном агрегате нет - мне такого не надо. Значит после ошибки уникальности ИНН надо вручную дропать первый агрегат?

Ну а по поводу актуальности и нужности. Клиент говорит "я хочу чтобы для вот этих ошибок было понятный ответ, а не неверные данные, кто то зарегался под его емейлом или  использовал его ИНН и что именно из этого". Вполне нормальное желание.

"но как говорят сам подход с предварительным select - не айс. "
А почему он не айс ?)

Ну как я понял из беседы до этого: rc, + так же выходит дополнительный запрос а то и несколько, который можно избежать проcто отловив constraint exception. Короче это не по взрослому :)

Так а зачем тебе-то это, если у тебя нет rc?
"Короче это не по взрослому :)" - это не причина тащить, что-то в проект )

Основной посыл в том, что предварительный select ничего не гарантирует -  на него нельзя полагатся.

Исходя из этого истекает, что есть разные пути:
1) делать предварительный select, но не опрадывать себя тем, что всё будет ок с реальной вставкой и получать constraint exception
2) быть на шаг впереди и искать причины и пути избежания таких ситуаций - на фронте заранее проверять потенциальный конфликт (можно сказать что это тот же "предварительный select", только теперь бекенду не обязательно отдавать удобную информацию об ошибке, если всё равно ситуация возникнет)
3) быть на два шага впереди - если уже пошла дублированная вставка - может это не такая и проблема и менеджеры смогут выгодно вручную разрулить ситуацию (бывает и такое) для всех