Where should virtualenvs go in production?
Here are my thoughts:
Arguments for grouping in a common folder

Cleaner management of multiple venvs on a given machine. Good tools to support checking which are available, adding new ones, purging old ones, etc.
More sensible (and more space-efficient) when sharing one or more venvs across more than one project
Allows the use of some nice features like autocompletion of venv names

Arguments for keeping with the project

Clear relationship between the venv and the project. Eliminates any ambiguity and less error-prone since there's little chance of running the wrong venv for a project (which is not always immediately evident).
Makes more sense when there is a one-to-one relationship between venvs and projects
May be the preferred approach when working in teams from separate accounts.
More straightforward when deploying across identical hosts; (just rsync the whole project). Nothing stopping you from doing this with a venv in a common folder, but it feels more natural to deploy a single tree.
Easier to sandbox the whole application.

I tend to prefer the former for more experimental / early-stage work, and the latter for projects that are deployed.
When using virtualenv (or virtualenvwrapper), the recommended practice is to group all your virtual environments together ... for example in ~/.virtualenvs
BUT, I've noticed in reading a number of articles on deploying Django applications, that the recommendation seems to be to put your virtual environments somewhere under the root of the individual web application ... for example in /srv/www/example.com/venv.
My questions are:

Why? 
Would it matter if I went one way or the other? 
And is one way recommended over another?