Tags have proven to be far less scalable than we’d thought when we did the original design. They work, but IMO we should be cautious about adding more tags simply because of the scalability implications. Apart from anything else, trying to decide the correct ordering of 1000-odd tags (much less N times that) is going to be tricky and error-prone.
To be more precise, pip doesn’t support plugins because we have no supported API. So plugins can’t actually communicate with the main pip code in a way that will be stable across pip versions.
That’s not to say that we’d have a problem with calling a well-defined hook interface (much like we do with build backends). However, any such interface would need to consider that not all installers are written in Python any more, so firing up a Python interpreter to call a hook might be more overhead than we want (this will end up somewhere in the resolver, which is pretty performance sensitive, but maybe it can happen once before the resolver starts?)
The main one is Create a supported "high level" programmatic API for pip · Issue #3121 · pypa/pip · GitHub. There’s also How to create plugin for PIP · Issue #3999 · pypa/pip · GitHub. As I said above, though, plugins are very different than “calling a standardised hook provided by another package”. The main issue with the latter is simply standardising something.