You answered it yourself: reviewers missing the forest for the trees, causing reviews to devolve into pedantry. Also: unpredictable code reviews where expected style changes every commit, because the dude do it by guts and feel different every day. Also: reviewer repeatedly forcing me to make changes that make code worst and reviewer changing requirements because he likes that better. It is super annoying when your code is "wrong" because you read best practices article reviewer did not, reviewer wont listen and still blocks commit till you change, only to have the very same reviewer forcing the same on you three months later when he found article and don't remember former discussion. I would much rather fixed a bug then went through above again.

The sort of people the most eager to do code reviews are developers with "every detail my way or the highway" unable to convince others they are right if they dont have ability to block commit. That and insecure people covering fear by aggressiveness. When I was in team with bad code reviews, review of a small patch could end in hours long arguments over variable name. Which of the two synonyms is better?

The thing is, code reviewing is supervisory function as any other. It is very easy to screw it up and especially people on the spectrum are likely to screw it up despite being good programmers when working alone. The usual "if you disagree with reviewer you have huge ego and cant take criticism" paradigma people push when talking about code reviews makes things only worst.

Of course code reviews can be done in good way too, but many of them are not and people have bad experiences with that.