The major difference between Gerrit's and GitHub's workflows are how changes are modeled.
In Gerrit, every commit is a change that stands on its own. Although Gerrit will show you the relationships between commits, reviews are performed on a per-commit basis. Teams that are good at breaking large changes down into small, self-contained commits are likely to have more success with Gerrit. However, since Gerrit's model includes successive revisions to a particular commit it encourages Git workflows that many developers are not accustomed to, such as amending an earlier commit and re-pushing it, or squashing a growing set of commits from a topic branch into a single commit.
In Github, a pull request models a relationship between two branches. The expected workflow on Github is to commit one or more changes into a topic branch (often in a fork of the repository, but not necessarily) and create a pull request between that branch and the "upstream" branch. In this case, what is being reviewed is a set of commits that continues to grow as the review continues. The result is a set of changes that can then be merged atomically when they are complete. Pull requests can be effective at tracking changes with a larger scope that may be implemented over multiple commits. Pull requests also support SCM workflows that more developers are accustomed to, such as responding to a review comment by submitting a follow-up commit in the same branch.
A big advantage in Github's favor is the number of developers that are familiar with it compared to Gerrit. Gerrit can be popular with Git power-users, but friction-free use of it requires intermediate or advanced git knowledge, and tolerance of a steep learning curve.
Gerrit's advantage is a deeper relationship with Git. Github Pull Requests are far enough removed from Git's standard data model that one must use either Github's web UI or its proprietary API to create pull requests. Gerrit's interface for creating and updating changes is the git protocol itself.