The point about GitHub today is that being "the best there is" is as irrelevant to its continued success as "being the best microblogging service there is" is to Twitter's.
Open Source projects move to GitHub because their users are all already familiar with GitHub from all the other open source projects that use it. That means those people already have a user account, know how to check out your code, are able to file issues, and can probably make contributions even if they're not very familiar with git, for example using one of the GitHub integrated GUIs that will handhold you through making a PR. If you are an odd-duck project using some other infrastructure you don't have any of these advantages, and the barrier to entry for potential contributors is correspondingly larger.
For users having a near-monoculture of source code hosting has all the same advantages but reversed; it means they only need a single account, and that every process they learn — all of which are well documented across the web — is fully transferable between projects. It also gives them a recognised place to show off their own code, and increasingly people are asking for a link to a GitHub profile as part of a hiring process. This even happens at Mozilla, an organisation that doesn't actually use GitHub for its most prominent projects (but increasingly does for new things; the advantages I mention here are valuable even when you already have everything set up for using something else).
Another benefit enjoyed by projects that use GitHub is the plethora of tools designed to integrate with it; again little to do with the intrinsic merits of the tool and everything to do with network effects (although I will allow that the API is generally very good). So if you chose an alternative to GitHub you might miss out on IDE integration, Travis, landscape.io, reviewable.io, or any number of other third party tools that either exclusively work with GitHub or have smoother integration in the case of such a well-worn path.
Tools like reviewable.io are interesting because they are clearly making up for deficiencies in the GitHub platform itself. In that case it's the totally, utterly, useless code review functionality in stock GitHub. And there are many other things in the site that could stand to be improved. For example the notification system that either spams you with every comment from a repo or ensures that you miss anything you don't check via the web UI. The permissions system that makes it impossible to add commits to a PR against your own repository without losing all the metadata associated with the PR. The issue tracker that doesn't allow assigning issues to anyone other than a project admin. But, from a business point of view, none of these things matter because GitHub isn't popular for being the best. It's popular for having been good enough for long enough to become ubiquitous, and now not being so bad as to negate the enormous network effects.
So the core of the problem here is not whether or not the authors, or anyone else, can build a better GitHub. The problem is that even if they could it would have to be wildly, dramatically, better to even provide competition. And so people, without meaningful leverage, resort to writing open letters and hoping that they can drum up enough noise that someone at GitHub chooses to care.