Github's popularity has made all other project hosting platforms irrelevant. Git's popularity means that every potential contributor knows how to use it, which significantly reduces friction for new ones.
I understand that git transcends organisation, programming languages, and operating systems. I still don't want to be stuck to the git way of doing things, no matter how popular it is. Concessions have to be made for git users coming to hg, but there are some things that hg does that git just will probably never be able to.
I may one day work on improving hgit, which is an hg front-end to a git storage backend proof-of-concept, but so far the hg-git workaround for git's popularity is good enough for most purposes.
That's not the case for GNU Octave or Linux. Those offer significant financial, ideological and technical benefits over alternatives. Benefits a large part of their user base actually cares about. Hg doesn't have that luxury. Git is simply good enough and hg is not good enough to offset the cost for choosing the unpopular option.
The HN crowd loves to chase what's "trendy" without thought for if it's a good fit for their problem.
GitHub frankly is a terrible solution for anything but an open source project, and even then there are plenty of better alternatives.
if your project relies on the popularity of GitHub to attract contributors I would be more worried about the nature of your contributors than where the code is hosted.
I also don't think that GitHub is a universally perfect solution. It's clearly not and I never said they were.
Using GitHub's popularity as a marketing measure is also not a binary choice between not using it at all and relying on it completely.
And by the community, I do not count those not having made any contribution but complaining about what is there in the first place.
This case is about the toolchain, but the same could be set about the code. Does it has to stick to an imperative form, as it is the most common widespread and understood paradigm, or can it be functional because it fits best the original design?
As long as the API is clean and the documentation is clear, I'm fine making the little extra effort to enter the world of the author rather than him/her lowering his/her expectation about what the project, as a whole, should be.
If your biggest complaint with hg is MQ, rejoice: there are modern alternatives that make MQ almost obsolete unless your current workflow already heavily depends on MQ.