As the creator of packaging.tags and thus as someone very likely to get pulled into helping maintain it as a separate project, the reason is overhead. We all know that keeping a project running has costs, from cutting releases, etc. so it isn’t free no matter how miniscule it is. And as of right now the packaging team is big enough to make keeping packaging.tags up-to-date not too bad. But break it out on its own and I don’t know if that “ease” will continue.
The interface is in a PEP, but actually inferring what those tags should be is very much not specified. It took me months to figure it all out and to make sure it made sense (hence why I found so many tags that e.g. PyPy was getting left out of).
And looking at all of the packaging.tags issues shows to me that the issue rate is not zero and has been pretty consistent since it started being used by other tools.
As a microcosm, sure. But what about the total dependencies pulled in by the typical (or even small) project? Is this still going to be the biggest contributor to disk space and network usage? I honestly think putting in the effort into Improving wheel compression by nesting data as a second .zip and Making the wheel format more flexible (for better compression/speed) would lead to greater gains than what we are discussing here (and I’m saying that as the person who sparked those discussion precisely to try and help with disk and networking utilization).
I would be supportive of such a PR in this specific case.