This point isn't too bad yet. As you've seen 2.4 had a security update a few days ago. Sure, it's from August, but 2.6 isn't doing better anyway. Some Debian kernel team people (such as Horms) seem to be dedicated to backport upstream's security work. A better question is whether there will be active security support for 2.4 if it sticks in Etch. This is unlikely to be much the case, considering that with the number of regressions in 2.6 continually dropping, when Etch releases 2.4 will probably look nearly as bad as 2.2 did when Sarge released (that was, no upstream release since over a year). So if we want 2.4 in Etch and decent security, the kernel team may have to do better than upstream... Another more interesting question is whether it's worth keeping 2.4 in Etch (which should mean about 3 years of backporting) assuming that the stable security infrastructure isn't fixed before Etch releases. 3.1r1 was delayed due to kernel updates, and when it's ready to be released it has a 4 months old package. 3 months of updatedness gained, 4 lost. In this context, if the security team doesn't change, removing half of the kernels would be a real help for the security of the rest of stable.Are we seriously expecting to ship etch with 2.4 kernels? Is anyone still doing active security support for it?
But for the first question, if there isn't a decision (and I don't know by who and how this decision will be made) about this in the few next monthes, the not so long schedule for Etch may make it impossible to do such a large change IMO.