Maven Central is a vital resource for Java, Kotlin, and other JVM communities. It provides the most popular repository for open source libraries, developer tools, documentation, and other artifacts. This service is heavily used not only by developers but also by CI/CD pipelines and automation tools.
// Disclaimer: I’m going on a bit of a rant here, sorry in advance…
So besides telling everyone “host a maven mirror yourself”, another way to achieve less repository traffic - one that would require little to no change at all for projects btw - would be a more intelligent / flexible artifact caching mechanism.
To be honest, every time I dare touching a project that hadn’t been touched in a couple of weeks / months, it seems Gradle needs to re-download the world. I have plenty of drive space, I’d be absolutely fine with Gradle taking 10 or 20 GB of that space to keep a copy of the most recently used maven artifacts. We mostly use similar stacks in our projects, so except maybe for different versions, we don’t even have a lot of variance in our dependency trees. Yet the amount of (re-)downloading done by Gradle over time is astonishing.
Also “yeah, we know that not being able to specify a mirror for Gradle plugins is not great but hey, there’s a way to hack around it, in just 50 lines of init-script, see?” doesn’t seem like the best messaging to achieve your goal. If you really want to support central by causing less traffic, why not make it easy for projects to achieve this in the first place (more flexible caching, mirroring capabilities) and then write a blog post about it?
Don’t get me wrong: I agree that enterprises or even big multi-dev projects should think about hosting a maven mirror (we do). But from Gradle’s perspective… let’s say there seem to be more useful tasks to spend your time on than this blog post imho.
// ** Rant end.
Anyway, thanks for all the hard work nevertheless, keep it up, we love Gradle 
The “put up a mirror” was more coming from the original post of Sonatype CTO which host Maven Central, that blog post seems more like a follow-up to show how to achieve it with Gradle today.
Besides that, I don’t think that such “redownload of the world every few weeks” when you change context is that much of a problem. Problematic are most probably more CI/CD pipeplines with ephemeral build agents and neither a repository mirror nor a shared read-only dependency cache, which means that each and every build by that CI/CD pipeling will re-download the world.
Besides that, you can already configure the cache-cleanup or even disable it, and it is desribed in the userguide: Gradle-managed Directories
So you should easily be able to achieve less downloads for your work style. 