They may be able to pull it off with the kernel, but they can't possibly do it for all their packages. As an example: How are the Django backports to 1.2 more stable than upgrading to 1.3 when the official Django project has stopped supporting 1.2?
Since the release of Django 1.4, version 1.2 stopped receiving security fixes by the Django development team. What that means is that a Debian maintainer (which probably is not a Django developer) would have to hack any new security fix into the unsupported 1.2. And this is deemed more stable than say, upgrading to 1.3.
Note that Django is just an example, obviously there are many more packages with the exact same problem.
But if that works for you, then great :-)
Besides missing the origianl point, comparing pip to tarballs just seems wrong. One is pretty much manual, the other is via a package manager, albiet not the distro specific package manager, but one specific to the domain you are working within.
"But then why am I using Debian?"
Personally, I tend to stick with everything from debian direct, but there are lots of domain specific developers who'd rather have the up-to-date stuff and I can't entirely fault their desire when we're talking about real world benefits of new versions. You still benefit from the stable base even if you want to run something up-to-date. You don't see the benefit of that?
Going forward from that, you can still pip in specific versions, update projects seperatly, and obviously test them before doing so, so while you may lose some advantages, living in a specific pip world doesn't seem like the end of the world to me, as long as there's a positive reason for doing so.
And it works. Most of all fixes are done by A or B, but the promise is one which the security team takes very serious. For one release, the security team backported security updates for 4 years. A achievement of taking responsibility in a "open source" project if I ever saw one.
Which sucks, because application software needs to handle environments with Locale::Maketext 1.19 differently to environments with 1.23, else you get double-escaping bugs.
The response? Reporting the actual, correct module version (or god forbid, sync the comments/POD as well) instead of the incorrect, unchanged version number "would break stuff". As opposed to incorporating a breaking API change without bumping module version, which also breaks stuff... Ouch.
I guess I only have myself to blame, I should be more involved with debian maintenance of packages I care about.
Obviously this is a lot of work (patches, managing dependencies, ...) if you do it for everything, but if you stick to the most important packages (e.g. nginx for your webserver, postgres for your db server, ...) I think it's manageable and will give you a lot of benefits.
(Thinking about the Debian OpenSSL fiasco a few years ago, I guess one could make an even stronger argument, though to be fair it was a pretty extreme case and I don't think anything like that has happened since back then.)
//Edit: I got curious about the OpenSSL issue from 2008 and it turns out that the Debian maintainers weren't solely responsible for the bug[0].