You may be underestimating what a package manager has to do. In particular, if it’s going to do dependency resolution (and people will want it to), then it may have to solve rather difficult mathematical problems that will indeed be CPU-bound.
I don’t think that is true. The reason is simple: many, many end-users/developers will eventually be in a situation where they have an old project using Python 3.X, but also start working on a new project that needs (or uses a library that is new enough to need) a later Python 3.Y. And they don’t want to upgrade the Python version in the old project, because that will require updating a bunch of libraries as well, and they don’t want to disturb the working configuration they have.
That situation is unsolvable without Python version management. Moreover, even if you don’t absolutely need to have the later version for the second project, you might still want to get it, or just to try something out, without having to screw up your carefully-prepared dependency stack in existing environments.
It’s the same reason people use venvs in the first place: they want to have independent environments, so they can, e.g., try upgrading a library in one environment to test it with a given project, or because different projects have incompatible requirements. All of those situations apply just as well to the Python version.
I see it is as much better in the long run to shift to regarding Python as “just another dependency” — because, well, it is a dependency. When you have a piece of Python code, Python is part of what it needs to run, and there are constraints on what versions of Python will work, just as there are for other libraries. It’s only the limitations of current tools that make us accustomed to managing Python separately from all the other things in the environment.
It may not be needed in such cases, but having it available does no harm. Moreover, in the long run, I don’t see any reason why Python provided by the OS, or by python.org, should not be actually a manager that manages Python. In the case of Linux distributions, for instance, I think this would go a good way towards alleviating the problems we currently have with “the system Python”. If “the system Python” is just an environment among many, then it becomes much easier to explain to people that they should create an environment for their own work that is separate from that, and it becomes easier for them to do that as well, because the tool to do so is already built in.
That is potentially true, and I agree that that might be the rare case where the manager might not be used. However, as you say, such platforms are niche. The vast majority of cases will not require such special handling. Plus, people who have to deal with such situations will usually already know they’re likely to have to do some extra work to get things working (e.g., compiling Python themselves).
In my experience a lot of frustration that people have with Python package management comes from getting into a situation where they try upgrading, downgrading, or removing packages for some reason (e.g., to match versions available on a server they want to use), and then find that in doing so they’re put the environment into a broken state by getting the dependencies out of sync. Ensuring correctness of the entire dependency graph on every package change operation prevents this; the only way you can break the environment is if a package itself is broken or its metadata is incorrect.