With respect, it's not a very common use case for a developer to say that package needs a python interpretor 'older' than 2.5.
Of course it is. I don't claim it is the majority of cases out there, but stable versions of many of the packages I use will specify an older python (Mailman and Zope both specify a range of Pythons, rarely including the most recent release, and Bazaar, although it tries to keep up with Python releases, tends to recommend being conservative, sticking to release (n-1) for the first few months into release n.)
And in fact this case is often more the important one. Packages that depend on having a *recent* version of python will often crash quickly, before doing permanent damage, when an undefined syntax, function, or method is invoked, while packages that depend on a quirk in behavior of an older version will typically silently corrupt data.
imho, all that they would know, is that they're using python (for example) 2.4 or 2.5 (pick a python version) and they know it works pretty well.
If they want to specify a Python version that works, they may as well bundle it, and many do. But even in that case the user may want to know about the dependency.
BTW, *all* of the Python applications I really care about make a point of specifying a range of versions they work with (or bundle a particular version). So in fact many developers do know what versions work or fail, and often why (and they sometimes even provide workarounds/patches for adventurers who want to use a Python outside of the recommended range).
It's then up to the user if they want to use it on any other version.
This is often an undesirable posture. From the user's point of view, the system version of Python may have passed various local tests and therefore be strongly preferred (for example, requiring far less time for approval from the security team). This is especially true for mail or web applications and other applications that must run in a very hostile environment. Many developers do want to provide this kind of information to such users.
I think you should rethink your position on how valid your personal intuitions are for generalization. You are certainly representative of a certain important segment of developers, but I don't think you have a good sense of the very broad class of requirements that other developers are bringing to the table.