I see where you are coming from, but there are legitimate concerns with the language package systems such as pypi. For one thing, pypi is unvetted, and the problems that bring should be obvious by now.
Another thing is that many move only the tip and older versions seldom gets fixed. If you introduce a dependency in a core package you take on the work of maintaining that version as long as the core package lives, which may be much longer than the upstream author wants to work on it.
The language ecosystems usually don't bring any stability guarantees. Just because the upstream author thinks a new incompatible version is the bee's knees doesn't mean core packages can suddenly be rewritten in the middle of stable period. So there needs to be a system for maintaining these packages in place anyway.
And if it's something distributions generally know how to do, it's packaging software, so it's pretty natural they use what tools they have available. The outcome isn't always great for the end user who wants unrestricted access to the language ecosystem, but that doesn't there aren't problems to solve here.
Another thing is that many move only the tip and older versions seldom gets fixed. If you introduce a dependency in a core package you take on the work of maintaining that version as long as the core package lives, which may be much longer than the upstream author wants to work on it.
The language ecosystems usually don't bring any stability guarantees. Just because the upstream author thinks a new incompatible version is the bee's knees doesn't mean core packages can suddenly be rewritten in the middle of stable period. So there needs to be a system for maintaining these packages in place anyway.
And if it's something distributions generally know how to do, it's packaging software, so it's pretty natural they use what tools they have available. The outcome isn't always great for the end user who wants unrestricted access to the language ecosystem, but that doesn't there aren't problems to solve here.