Distributed doesn't mean decentralized; they are not synonyms.
DNS is distributed, yet it has a "root" servers.
Even if there a master repository in a given git scenario, it is still distributed because developers have their own repositories, which are independent, and contain a replica of the copies of the upstream objects.
The point is that at least for a VCS, centralization does largely subvert the distributed aspect. At that point, you no longer really have multiple repositories so much as multiple working copies, similar to a CVCS. Your work model revolves around a blatant SPOF which you must synchronize all changes to.
The Linux kernel is a proper example of distributed workflow.
According to this text by Joel Spolsky, in SVN-days developers spent days and days massaging code but not committing, because committing meant pushing to the central repository public to everyone. With git/hg developers can use version control also in their incremental daily work, and finally merge or rebase or squash or whatever, to massage their work into a form that is good for pushing to the master.
That depends on what you want out of the "distributed" aspect. If all you care about is offline access to the repo, and like the fact that everyone's checkout is effectively a backup of what's on the central server, then centralization doesn't really take away from the distributed nature.
Even if you consider the SPOF-y nature of something like GitHub, more savvy git users will realize that if GitHub was down for an extended period of time, they could push their repo somewhere else that's public, like Bitbucket, or their own server, and keep working and allowing other people to collaborate. And for shorter downtime of the central server (where you might feel like setting up an alternate is too much effort), everyone can still get work done, they just can't collaborate as effectively until things are restored.
That works for the repo, but not issues, pull requests, wiki pages, permissions, or any other services GitHub provides. None of those work offline, and while there is an API that can help with migration, doing so still requires setting up a totally different system, and there is no natural backup on every developer's machine like with the repo - you have to do it manually while the origin is still up. (Not that GitHub is likely to disappear anytime soon, but all things will end someday.) Which is unfortunate because it seems like a missed opportunity: it's certainly possible to implement all those things in a decentralized manner, and some projects have tried, but so far with little success...
A central origin sure. It is nice knowing I can work offline which is my general workflow. I can also experiment with local branches and not push them to a remote.
DNS is distributed, yet it has a "root" servers.
Even if there a master repository in a given git scenario, it is still distributed because developers have their own repositories, which are independent, and contain a replica of the copies of the upstream objects.