Isn't worth the effort for who? I'd say it's worth the effort for:
Red Hat (RHEL/Fedora)
Otherwise how can you have any kind of reasonable expectation of security for your vendor kernels?
Why should they all individually have to be playing a guessing game on things that kernel developers already know but deliberately obfuscate? And again, before anyone brings it up again, it's not about the developers themselves trying to figure out if every bug is a security bug -- it's about not hiding or obfuscating what they are clearly aware of. In this case, for starters, it was clearly obvious to both Linus and Greg that a DoS was fixed for amd64 for which a trivial exploit existed. The developers were told by the bugfinder that it was a DoS issue and were sent code to trigger it. It seems obvious stopping this insane policy of deliberate obfuscation would reduce the ridiculous lengths each individual vendor has to go through to turn kernel developer weasel words into actual assessments of bugs.
As an example, the mremap "fixes" that went into the stable tree recently -- a huge set of patches with only vague descriptions of what was being fixed: Red Hat assigned it a cvss2 score of 7.2, saying that it was more than just DoS fixes (7.2 puts it in the highest category of severity, if you weren't aware). Ubuntu (and I believe another distro) just released an advisory for the same set of fixes recently, saying that they only fixed a memory consumption problem leading to a DoS. This is the kind of confusion "a bug is just a bug" causes.
What we know for sure is that "they" (being the kernel developers) don't care about telling us about security bugs once they learn they exist. Greg didn't mention the amd64 DoS by name, and all the commit messages involved in fixing it avoid mentioning it as well (Linus' work here).
While we're on the topic of fixing security bugs though, one security vulnerability that wasn't fixed in 188.8.131.52 was the move_pages() infoleak, which affects kernels >= 2.6.18. If you're running RHEL 5.4 x64, you're vulnerable to the infoleak, which unlike the recent leaks of tiny amounts, involves a leak within a 512MB range. It was posted to oss-sec 3 days prior to the release of 184.108.40.206, and the fix was a trivial 2 lines.
Finally, I reported two security issues to a prominent kernel developer that affect all 64bit kernels since 2.6.26 several months ago and they've yet to be fixed. You'll be shouting your "a bug is just a bug" mantra until it's revealed months from now that there's yet another vulnerability in the mmap_min_addr code (making null pointer dereference bugs exploitable again) that would have been prevented if the issues I reported months ago had been fixed.