Earlier quoted context omitted.
Shallow and too late criticism sounds like a problem with how the reviews are handled. At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved. I also found it a great way to catch subtl…
Logically, any review criticism is too late, because the code was already written! Catching the issue before commitment is great, but the proper time for the feedback was during the actual writing. Now the code must be sent back for rewriting, and time has been wasted.
But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. In my experience the vast majority of tasks are easily addressed by a single person and most proficient programmers will usually produce perfectly adequate code which doesn't raise any concerns. Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) but saves a lot more time and effort in avoided bugs and issues than the cost of having to rewrite something every now and then.
Additionally, any single submit should be kept to a manageable size so that they're easier to review and issues are caught early. The only times I can remember having insisted someone rewrite something non-trivial have been when they misunderstood some fundamental issue, did not communicate progress as they should have, and did not follow guidelines of solving a single task per submit. That type of behaviour is in itself a pattern which needs to be addressed.