The issue is you think pyenv has solved everything, someone else thinks poetry solves everything, I think uv solves everything, and someone else is apt installing things. And then there is installing torch and cuda...
I think having a very widely accepted and supported default would let the community rally around it and improve the experience and documentation (though I am not a fan of the centralized hosting that npm and cargo push, I much prefer the go approach, but we are already there with PyPI)
uv + poetry are a higher level in the stack than something like pyenv.
pip, uv, poetry are all analagous. they ensure the correct packages are installed. we have some internal apps that devs decided to start with poetry and it has some nice ergonomics ... but on the other hand I find the simplicity of a requirements file to be so ... simple. People get caught up on the file, too, but really its just a convention. you can call it whatever you want, deps.txt, deps.foo, packages.bar ... its just a plaintext file with newline delimited packages. since its "just a file" and "just unix" this has the added perk of being able to cat many files together and use that with pip. it's all just lines of text, pip does not care.
pyenv + pip works. pyenv + poetry works. pyenv + uv works. those become inconsequential decisions you can make on a case by case basis and try or forget as needed.
You're right not all of those need to be conflated but they aren't entirely orthogonal either, uv can install/manage python installations for you and poetry can manage environments as well if you want. On top of that, you have tools like mise that are more cross cutting.
I agree that there is a really nice simplicity to requirements.txt but I've myself enjoying uv enough to just fully embrace it (and not farm out to uv pip) and as a result I now find myself in pyproject.toml land.
I think having a very widely accepted and supported default would let the community rally around it and improve the experience and documentation (though I am not a fan of the centralized hosting that npm and cargo push, I much prefer the go approach, but we are already there with PyPI)