This author, and 99% of anybody writing about, and large majority of anybody attempting to do code reviews misses that there are two very distinct and not particularly compatible purposes of code reviews. IMO the only really important one is identifying code that doesn't do what it's supposed to, either because the author miswrote it or misunderstood the requirement. Critically this is just "what", not how or why. This is often really simple stuff, like getting a sign wrong or storing a value to the wrong field/variable or using && instead of ||. 100% objective stuff. The other purpose I'd more broadly describe as "design review", which is focusing on "how" the code should have been written. In my experience this is mostly subjective and that's what consumes all the time. My suggested approach is to officially delineate the two, and whenever someone raises design or style issues in a code review just say "that sounds like a good topic for the design review". You can actually use PRs for both purposes, just front load the "design review" during the WIP phase for a feature branch, and then do the "code review" before merging into a mainline.

Real world example: a company I consulted for a couple years ago had a lead architect known for nit-picking code issues with junior devs ad nauseam (to the point where potential hires were told to expect it and not join if they didn't think they could take it). Their production system was brought to their knees by a doubled for loop, literally just a duplicated line of code. This code copied messages from one place to another, but almost all of their testing used cardinality 1 so it didn't affect the tests. In production all it took was a couple cardinality 2 cases because there was one edge case flow that could route copied messages back through the loop and this caused cascading failures as 2 became 4, 4 became 16, etc. This error would have been obvious to anybody reviewing the code, even if they didn't really know much about it, but as that module was written by said architect no one else felt qualified to review it.