You can certainly just delete a venv. `rf -rf venv`
I'm not sure what kind of custom path you need, but you can put a venv anywhere you want that's practical.
Yes, when you create it, you need leave it there. but they're trivial to create. `python3 -m venv [path to venv]` Installing packages is a LOT faster than npm.
There's definitely issues with python's setup as a global interpreter, but these arn't them.
I hate this question. It's basically "why are you stupid"? I'm a professional with 20 years of experience with ecosystems ranging from Java, .NET, Ruby, Python, etc., so if I write something, I probably have a valid use case.
The opposite question should be asked: why can't I do that?
And the answer is, frankly, either lazy/bad design on the Python ecosystem part or backwards compatibility with an existing but bad system. In a well designed system venvs would be by default copy-able to another equivalent system since there's little to lose and a lot to gain, for example, access to the simplest and most reliable deployment system invented in history, the <<copy-paste deployment system>>.
The fact that we have entire generations of developers that can't fathom why someone would want that basically says all it needs to say about the degree of over engineering that's now standard.
These days I just use virtualenv since at least it's simple to use and reason about. It's bad, just not nearly as bad as the others I've tried.