Date based

in my opinion you should care about how old the base of a kernel is.

there are a _lot_ of things that don't get backported, some is hardware support, some is performance improvements, some are cleanups of code that may or may not fix bugs, some are bugfixes that people don't think are important enough, some are bugfixes that are considered too intrusive/dangerous to backport.

the number of people working on doing backports is rather small compared to the number of people working on the latest versions

look at the number of patches in a -stable release, even the big ones are seldom more than 100-200 changesets, out of the 10,000 or so changesets in each new release. even if there are a LOT of -stable releases for a particular kernel, the number of changes that get backported are considerably less than 10% of the changes that go into the next release, and as a kernel gets older, fewer changes are backported. by the time you get to a kernel that's 10 releases back, I would guess that far fewer than 1% of the changes have been backported

actually, we can look at numbers for this (fun with git)

2.6.27 - 2.6.37 had 113521 changesets
2.6.27 - 2.6.27.57 had 2891 changesets

2.6.32 - 2.6.39 had 76108 changesets
2.6.32 - 2.6.32.27 had 2892 changesets

2.6.38 - 2.6.29 had 11031 changesets
2.6.38 - 2.6.38.7 had 3101 changesets

so I was a little off in my 1% guess, and I don't have the most recent versions of all the longterm kernels (I pulled from kernel.org and from the stable tree)

but do you really want to bet that the rest of the changes that did't get backported are really all for things you don't need?