"Given bug A and bugs B1-26, I think I should apply a patch for A but not for B1-26. Why is this bogus?" where:
Bug A is the subject of a long rambling Bugtraq post "Linux security is a joke" which claims that there's a serious buffer overflow and that it will "inevitably" be exploited in the wild. Linux writes and commits a two line patch, and nobody makes a working exploit, because unknown to everyone a structure alignment decision by the compiler makes the exploit condition impossible in the real world. Thus Bug A is a "security bug".
Bug B14 is 14th in a list of 26 patches fixing clearly incorrect use of an API for accessing the PCI bus. Only three people even read it, and Linus applied it because it looked similar to the other 25. But in reality it happens to fix a problem where anyone with access to play sound through an HDA compatible sound chip can also read & write arbitrary kernel memory using the right parameters to mremap(). Eventually someone will stumble on this problem and produce a POC, but not today. Thus Bug B14 is "not a security bug".
The answer is that it's bogus because it gives you (or your users) a false sense of security. You've fixed the "security bug" but actually you spent a lot of cycles on something that had no practical impact and left out the most important fix for something serious. Waiting three months for Bug B14 to "become" a security bug makes little sense, the fix is right there now. The easiest path, upgrading to stable, is in fact the best option if you don't have the cycles to do your own due diligence.
If you struggle to buy this argument, imagine that I have the set of all bug fixes, in the form of a hypothetical git branch against 2.6.27. Since my branch has no bugs, it also has no security bugs. Now, to cherry pick from my branch just fixes which you think are "security fixes" will certainly not produce a kernel which has /less/ security bugs than mine, indeed it will probably have more. Do you see?