"GitHub PRs/issues are native to GitHub". If you switch to Gerrit, the code commits themselves follow, but the PRs and issues don't. They're only on GitHub.

I wouldn't point to gerrit as an example of self-hosting git. Gerrit's "patchsets" and "change-id"s concepts, as well as the weirdo remote push refs, really turns the git experience into something... very different. It's very far from both how "normal" git commits and tracking branches workflow work, and from github/gitlab/bitbucket's pull-request/merge-request style.

How is it not a an "example of self-hosting git" when it's built on top of git?

I understand from your comment that it's not your preference but that doesn't mean its not a self hosted git solution.

Because the gerrit workflow is extremely different from all other common git workflows (which is to say, you build a set of commits in your own branch or fork and ask the maintainer to pull it). Gerrit actively encourages you to rebase and rewrite (and lose) your development history in the pursuit of a "perfect" one-hot non-merge history patchset, which actively loses information about the context of where your changes where applied.

The problem with submitting a rebased branch is that while there are no apparent merge conflict and your changes appear to have been developed on the tip of master, your changes may actually have been developed on a much older version of master. Builds may appear to compile fine but they might not make sense - when you discard and rebase the context of commits, you lose important information.