I really like Gerrit's workflow with diff reviews as opposed to pull requests, but unfortunately compared to something like gitea it lacks everything else we've come to expect from git hosting (issues, project planning, etc) which makes it seemingly a hard sell for many. I really wish there was a nice diff review platform kind of like phabricator but alas.
My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.
The number one thing that gerrit does that is important is keep comments tied to the code between commits.
By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit at the end instead of some dogs breakfast of merge commit with revision commits shoved in it.
How does that work? If the code the comment applies is to is changed, does it expand the range? Or try to relocate it or something? Or it just doesn’t try at all, and it just applies a comment to a certain change/diff section?
It does (hand waving) things to keep the comment in place. It doesn't always get it 100% right, but it's pretty good.
But more importantly, Gerrit has a "Change-Id" it adds to the git commit which is independent of the git hash, so it can track changes independent on the "logical" commit separate from the physical commit.
It also is able because of this to show you what changed for a given commented section between those commits. Allowing you to properly review the changes.
GitHub just acts like a dumbass and throws away comments or threads if the original commit is rewritten. And so forces you into this garbage workflow of endless "commit to address review comments" or "new version" commits, which then have to be either manually rewritten before merge, turned into a (garbage) merge commit, or squashed down into one commit.
1. Gerrit's approach requires a stable Change-Id in the commits. So it doesn't just work out of box with stock git. It requires that the submitter's git configuration and the repository be set up to support this. (Note that JJ supports this out of the box)
2. Cargo cult. We have a whole generation of software developers who grew up in this generation, love GitHub, and have never known anything else. The "PR" approach is considered orthodox. Unless they went and worked at a Google or somewhere like that, they've probably never been exposed to alternative processes.
