IMO a practical benefit of a routine code review is just a shared understanding. As simple as that. Does the code look to be doing what it says it should do? Do the tests express the intended behavior?
Of course, the style, the quality of code could be of attention too, but that's extras, in my opinion, as long as the functionality is understood and confirmed.
I like relating this to an effort of understanding someone who speaks with an accent, be it a local dialect or foreign-originated. It does require some tolerance, but the shared understanding is the goal.
I've found this to be true in change control as well as any meeting involving people who feel they are compelled to "contribute" even if they don't have anything of value. You don't want to seem like the person who's just attending the meeting and slacking off, so if you're expected to contribute and you can't find any useful critiques, you just pick nits.
> everyone has their own style,
Which then you can asked is that not ALSO a red-orange-flag ? Should one of the metrics not be to be as 'uniform' as possible ? But I do get your point even with uniform guidelines etc, any seasoned def can quickly pick-up who wrote it.
I don't think so; someone's code 'handwriting' always seems to me to be more about how they think about problems than specific syntax conventions.
Everyone working on the same codebase should follow stylistic conventions - where do you put the opening bracket, how do you name functions etc. - but that still leaves a lot of room for personal style/approach. Faced with the same problem, two programmers might solve it in two different-but-valid ways, and that's recognisable.
This is a generally good idea, but in small teams it can't really work. Code is in that sense a bit like handwriting, everyone has their own style, and after a long enough time in a small team you learn to recognize whose the author of the code just by reading it.