They appear to be problems with the mindset of the developer instead of issues with the idea that another developer looks at their code.
For instance,
> More long living branches, more merge conflicts
makes the argument that a PR forces a long lived branch that will result in frequent merge-conflicts.
I could counter that the issue here is that a developer attempted to change so much that the branch desynced. If the developer made an effort to break up merges into smaller chunks, as the article proposes, then the fact that it lives in a branch is a moot point.
And merge-conflicts will happen regardless of PRs. If I'm pushing directly to the main branch to a file that was changed by another developer, I'm going to have a conflict.
The argument about "review-ability of a change decreases with size" also has nothing to do with branching. The same mechanisms the author argues for are valid with a PR. If you refactor something, commit, then make your intended change and commit again, the PR can be filtered by the change in each commit. So the only issue with review-ability comes to the size of the commit.
Something I do agree with is that numbers 4 and 5 can be a concern, but they tend to be an organizational problem and not something that PRs cause. If the organization has a policy of all comments must be addressed, superficial comments can cause a blockage. My experience, though, is a small amount of discussion unblocks them quickly.
The last thing I'm going to address is "It’s easier to fix than to explain the fix".
This is something that modern SCM tools have addressed by allowing a suggested fix where the reviewer can just make an inline change that the author can choose to accept. i.e. Github has this ability and a button that allows the author of the PR to commit the change to the branch.
A few of these issues "might" be things that a PR could exacerbate, but this list seems to be more trying to fill out to number 10 than adding actual substance to the debate.
