Нельзя просто так взять и предвить все тонкости при проектировании архитектуры. Многое будет переделано в процессе. И после добивания получающегося таким образом кода до состояния “вроде работает, старое не отвалилось, надо мержить и выкатывать” что-то менять в нём уже не хочется. То самое “что тут думать, прыгать надо”.

На этом этапе код-ревью бывает бесполезным - ревьюер занимается поиском багов (вместо тестировщика), либо докапывается до вкусовщины (вместо линтера). А всё потому что не хочется докапываться до архитектуры (и скататься во вкусовщину). Можно, конечно продавливать свой вариант авторитетом. Но бывает ревью между одноранговыми членами команды.

А что если не бояться скатываться во вкусовщину в вопросе архитектуры вносимых изменений? Что если относиться к предлагаемым изменениям как к рекомендации, а не как к требованию? Форкаешь вливаемый форк, делаешь рефакторинг на свой вкус, предлагаешь к принятию и объясняешь почему так сделал. Тестируешь, ясное дело. Готовое решение гораздо легче принять. Вдобавок из него легче выхватить отдельную идею (если с чем-то согласен, а с чем-то нет).