Excelente pergunta! Na minha visão, essa dinâmica funcionar vai depender da senioridade das pessoas envolvidas e, principalmente, da maturidade que as pessoas tem sobre o design/engenharia da aplicação. Por "design" eu não quero dizer a interface, quero dizer a engenharia por trás, a arquitetura, modelagem e a visão de longo prazo para onde o projeto possa ser levado.
Então se uma equipe é formada apenas por pessoas com uma alta senioridade em tecnologia, e uma alta maturidade no design da aplicação, eu faria sim o tradeoff de deixar o Code Review opcional por uma velocidade maior (e muito maior) de interações com a base de código.
Do contrário, eu não faria isso, pois o mecanismo de revisão é o que faz estes dois fatores serem construídos num time, principalmente o segundo fator (design).
Bom ponto de vista, com o seu comentário você responde o segundo questionamento, do qual impacto isso pode ter no software.
Talvez se tivesse como identificar se o PR é critical, major ou minor poderia aplicar para os minors, que geralmente é uma implementação não tão sensível como um critical ou major.
Filipe, você enxegar um cenário onde exista uma equipe apenas com seniores, ou então já participou/viu uma equipe assim?
Minha pergunta é motivada por um vídeo do Akita. Busquei a parte específica que veio à minha mente, mas não achei. Se não me engano, ele comentou que toda equipe precisa ter juniores, porque nenhum sênior quer fazer as "tarefas simples" que são repetitivas para ele, mas que para um júnior seria bom fazer.
De qualquer forma, na minha busca achei este vídeo do Akita (blog post), no qual ele comenta sobre revisão de código, juniores e seniores:
Dado tudo que eu falei, se tem uma recomendação que eu faria primeiro a qualquer empresa, de qualquer tamanho, é que nenhum código deve ser imune à revisão, não importa de quem seja. Todo código deve ser revisado por alguém da equipe, de preferência mais de uma. Todo júnior precisa que alguém aponte o que ele fez de errado, o mais rápido possível. Todo sênior precisa se acostumar a orientar os outros e revisar o código é o primeiro passo. E pra escalar não tem nada melhor que pressão peer to peer, todo mundo olhando todo mundo. Se isso for rotina, fica muito fácil pra equipe inteira notar muito rápido quem está entregando código, em qual qualidade e com que frequência, e não deixar os problemas graves se acumularem a níveis ingerenciáveis.