That is a very good point. I have been doing that for over a year now and I think it works pretty well.
We have a CI/CD that blocks everything that breaks existing code. So there is no merge happening.
If something breaks we fix it before merging. After that we immediately deploy to another environment with even more tests before going to production.
If by all means something that line anything fails, nothing will hit production before it's fixed.
Also. Even IF production breaks, there is no blame. The fix will go out immediately which can happen, even with review.
So
#NoRequiredCodeReview for me.
If you want a code review you can certainly request one 🙂.
I think there's a middle ground to be found between trunk based development and code reviews
You can have code reviews but don't block a merge behind it
Review it before it gets released to production