Many postings on code-review explain what good code should be, refreshing to read a posting on how a code-review should be done.
On pull-requests: I'd go even further, many times you should not do reviews via pull-requests at all. When you develop code in a team, all code should be (re)viewed by at least one other team member, preferably by more. Pull-requests are not the only way to do that, and when you work in a team, where everyone is on-site or easily reachable virtually, pull-requests are an overhead at best, and ineffective at worst.
If you pair- or mob-program, you have code-reviews built in your development ( from this friendly answer on twitter ). But even if you program at your own, instead of creating a pr and continue on your next jira-ticket, you can ask a team-member to review your code directly. Ask your colleague to sit next to you, while you let him or her view your changes, or share screen if you work remotely.
I totally agree with you but I see some advantages to use Pull Requests:
I don't tell we shouldn't do IRL code review, peer and mob but do pull request review in addition of the other forms of code review.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.