Of all Git users, only an extremely small percentage use Git as a DVCS (Linux kernel, etc). GitHub is a centralized VCS. In fact, I think you could argue that the emergence of GitHub is a demonstration that DVCS is nearly useless for the vast majority of software development.
I think you don't understand what makes centralized VCS different from distributed. GitHub is just another clone of the repo.
For example, I can commit in my Git clone, can create a new branch, merge a branch, push it to the server, all without GitHub server being available. If GitHub would be down or closed tomorrow, this would not significantly affect my work on the repository.
You can do all of this because Git repos are self-contained complete historical records.
You could do this with a traditional VCS as long as you took frequent backups. Git is an improvement in this regard, but not a revolution.
Furthermore, you are describing a workflow that is inconsistent from many "industry best practice" recommendations. If GitHub went down, a very large number of Git users would not be able to run tests or deploy their code to production - their CI/CD pipelines don't work without GitHub. Their historical record of issues goes away when GitHub goes down, etc.
With traditional VCS, I would lose all the history and ability to work (to commit my changes, for example) if server goes down.
And I understand that issues and CI/CD will also stop working, but neither of that is part of the VCS itself. I'm not aware of distributed issues (maybe FOSSIL) and CI/CD.
Still it doesn't mean that GitHub makes Git centralized.
