At one job I had we have team members up to 2pm the day after the review was requested to respond. If no one responded by that time we were allowed to merge it. This solved the problem of often waiting for days for a review and the review being lack luster.
As with all things in life, it's about balance. I have been more than happy to review other's code because I see it as more than just a critique. Often times it is also a learning opportunity by seeing their style or approach for example.
I have forced myself to be critical of my own code before others and try to keep it that way when it comes to reviews. There should be a standard of what to look for from language to language. This helps avoid style bike shedding with formats or naming.
I worked with someone who was definitely the nitpicker. He would even nitpick PRs that he wasn't a reviewer on and would happily unwind a merged PR just because he hadn't had a chance to review it first.
Many of the things that are often nitpicked can be automated with tools like linters. This really helps cut down on the pain of code reviews for both the author and the reviewer.
