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.
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.