I am implying that the hostname of the upstream DVCS repository does not matter to anyone who even remotely understands his shiny plaything.
Yes, this detail doesn't matter that much - there's an inconvenience in getting all the references fixed, and that's it. That you're suggesting this is the issue is silly, though, since it's really about #2.
Like what? The issue tracker? Indeed, it is a rather dumb idea to sacrifice yourself to voluntary vendor lock-in - but that's not Microsoft's fault at all. As if Microsoft would endanger your precious bug reports...
Issue tracker, pull requests, wiki, github pages, discoverability, the social aspect. The integrated two-factor auth stuff... teams... stats... the commercial support... access control... vulnerability scanning... GitHub is a really well-working and polished product. It gives you loads
of features you don't get with a bare "just a file storage bucket" repository.
You can't avoid vendor lock-in unless you go for an on-premise solution. It's been a while since I checked out GitLab (but they do both cloud and on-prem, right?) - but I've worked a fair bit with Atlassians Stash/BitBucket. It can run on-prem, but it's not open-source, and while it's a good product, it's lagging quite a bit behind what GitHub offers.
And sure, Git is a DVCS. But in and by itself it's not super effective for collaboration, especially when you're outside a single team or company... you need an additional layer on top of the raw DVCS. If everybody runs different systems, collaboration gets harder.
Every centralized repository is a single point of failure. IMO, the sanest approach is C's: You'll just get your headers/libs from your OS vendor.
You've got to be joking.
There's so much wrong with this idea that I don't even know where to start - that'll be for tomorrow