Earlier quoted context omitted.
The reason is maintenance. Once you set up yet-another-repo-mirror (after your apt, rpm, nuget, pypi etc mirrors), someone needs to keep it up, back it up, secure it, refresh the packages, etc etc. It's "cloud culture": rely on some else's maintenance effort and just work on your own problems. Like all things, it has drawbacks.
I don't buy it. You need a place to keep your own repository, and once you have that, keeping copies of other repositories is pretty much free. Keeping up, backing up, and securing N repositories is no more work than doing that for one repository. You can still outsource this, even. There's nothing wrong with using GitHub or Bitbucket or whatever for your repositories, just make sure that you're using your repositori…
Whereas standard "fetch package" scripts are trivial, and each individual stack is known well enough by developers working on it every day that there is zero administration and little need for extensive knowledge transfer... At least until left-pad disappears from under your feet; but that's rare enough that the trade-off is worth it overall (or people cannot even imagine it ever happening).
I'm not saying this is how it should be, I'm just describing why a lot of people do what they do.
Maybe the solution is an overall simplification and harmonization of all these services, so that the responsible option and the lazy option won't differ so much. You could have something like a prebuilt "repo server" image that can be downloaded and configured quickly, and which will then auto-cache all requested packages across different services. Cache invalidation would still be tricky but could be triggered selectively from an admin panel. Maybe all this should be packed into CI servers by default...