I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I can continue utilizing my git repo with all the distributed features it had before. I can (and have) continue to work while GitHub is down, I can export any of the additional data (issues, wiki, etc) that GitHub offers and store them just like I store all my backups, etc.
Centralized hosting solutions can offer value, even to distributed tools.
Where GitHub ends up conflicting with distributed workflows is when build pipelines or other systems are set up to rely on GitHub (Go dependencies, I'm looking at you). In cases like this, the user is making a choice to pin that piece of their infrastructure to a centralized service. And that's not always a bad call! If the value provided outweighs the harm done when the centralized service goes down or has other issues, it can be a good choice. It's up to the person designing their infrastructure to balance the risks and benefits, as with anything else.
Specifically speaking to GitHub's lack of incentive to invest in extending distributed git features: that seems counter to actual events. They recently worked to develop their large file storage, and rather than release a closed source / centralized system, they released an open source extension that ties in with core git (https://git-lfs.github.com/)
Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history properly without losing some details, so I firmly believe we have to make more of the git story distributed. Those features can be used by github in a friendly web interface, but like the git push and fetch model, it should exist in git itself. That way, it really won't matter where users make contributions, and it will solve the Phabricator vs github dilemma for big projects, plus allow for full archiving and porting of the data. Once your tickets and diff reviews are part of the git repository, you get features that enhance the user experience. I believe git-appraisal is using git's notes feature, and that's a good way to avoid extending the data model.
