I've worked for places that didn't have code review, and places with pre-production code review. The ones that didn't code review brought in code review practices (like they should). I have never seen a post-production review process though.
It is a terrible system. If you aren't reviewing code before it goes in you are missing a HUGE opportunity to review for bugs and correctness before a client experiences a crash.
But post-prod? Why even bother at that point? Might as well put off writing tests and so forth, too! Go BIG!
I'd rather continuously-deliver sub 1hr of changes to production several times a day. Pair & Mob programming provide continuous code review pre-commit, but they don't provide all the benefits of traditional code reviews. It can be valuable to sit down as a team and or with others who didn't work on some code and think through how to make it better/improve it asynchronously.
That makes no sense.
If delays introduced by pre-prod code review result in "bigger changesets", you're clearly doing it wrong. In fact, if you batch up commits to deliver to prod on some semi-regular basis, the exact opposite should happen.
Individual changesets would be exactly the same. Velocity may slow down (that is, it may take longer for any given changeset to make it to production), but you're producing higher quality code in exchange.