It's a system-wide tool, there's nothing wrong with installing it with sudo pip install if you want it on your PATH.
Packages not installed with the system's package manager should be installed elsewhere, e.g., a local install in a user's home directory, or (in the worst case) /usr/local or /opt.
Failure to comply with this rule bites hard when you install some other package that uses Python and pulls dependency from OS repository that you had already installed from PyPI. That obviously fails due to files being already present (and probably from another egg's version) and you're probably already using this egg somewhere so you probably can't readily replace it. Manual clean-up of such mess isn't pretty nor fun.
So, if you want a non-project-bound package (like ipython), do so with `pip install --user`. Otherwise, virtualenv is the tool.
(Obviously, there are non-trivial exceptional cases where sudo pip is fine. I believe they're quite rare.)
If you want a clear failure mode - if this installs requests globally, think about the chaos if you're on Debian stable, with 0.12.1, before the API break - after a pip install, you may end up with all the software on your system broken.
When this happens, please don't file bugs with Debian. Thanks.
We are all adults here. I believe the implications of using pip instead of apt on Debian are pretty clear for anyone using it. This is not an universal problem though.