Airflow is an extremely atypical example. As one of the largest open source monorepos, I understand that they want (need?) to be opinionated w/r/t their development tooling to stay manageable; that does not necessarily mean the same is true for the vast majority of other Python projects. Plus, even Airflow seems to have no particular opinion on the venv location—their contributor docs mention the .venv/ directory as a default location but also explain how to pick a different directory.
So, to answer @brettcannon’s original question—no, I think projects should not be able to dictate a venv location.
In particular, by dictating a venv location, a project would require that the venv is located in the project directory; and as Brett noted, a lot of people strongly prefer having their environments in a single central location.[1]
I like that this PEP is workflow-agnostic in that way—it both sets a good default for venv-in-project-dir workflows and extends it in an easily understandable way for venv-in-central-location workflows.
Personally, I expect this PEP will even help in the rare occasions where I have multiple environments for a single project; manually changing the environment in a single location (the .venv file) and then having all tooling pick that up from there would be an improvement on the status quo.
Overall, strong support; many thanks for the work on this! 
Including myself; mainly due to many years of working with conda as a physics researcher. ↩︎