имхо code review необходим когда у тебя меняется домен, структура данных или выходишь за пределы границы дозволенного.
junior работает в своей песочнице (класс, метод, функция, компонент), они не дизайнят ничего нового и риск того что они что-то сломают минимальный. в своей функции они могут делать все что они хотят. проверять их надо в первую очередь линтером и sonar qube с default quality gate. у джуниора есть тимлид который следит за тем, что джуниор пишет. джуниору можно позвонить в любой момент и попросить расшарить скрин. пропускать джуна через целый code review процесс не нужно.
плохо сформулированная задача решается методом review before code
требования complience - у каждого свое понимание как этим требованиям соотвествовать, н о это не должно сильно бить по экономике (code review бьет сильно).
Ну тут момент что junior что-то сделает и закоммитит, при этом он не научится ничему хорошему, а потом ещё другим за ним переделывать. Хуже того, у нас появится функциональность которая не покрыта тестами, или покрыта не достаточно