A turning point for CVE numbers

>The point of the CVE system should in theory be that it allows to quickly decide whether it's worth to drop everything on the floor..

But that does not and cannot work for something that is as wide scoped as the Linux kernel.
Even assuming the CVE does refer to a real vulnerability the impact is very usecase dependent.

A local privilege escalation on a server providing shell acounts is probably a big deal whereas the same vulnerabiliity on an embedded device that is only running the intended software (maybe already as root) who cares?

The problem is that CVE numbers are conceptually simple and hide a lot of the real complexity and nuances that need to go into their sensible interpretation and you end up with stupid policies that say "you have to fix all CVEs" (of course that's not directly the fault of the CVE numbers themselves but the way people try to use them).

Giving managers something they think they can understand and make decisions on when the realities are much more complicated is generally a bad idea.

Also in my experience updates in the same stable kernel series very rarely cause issues and those that ocasionally do slip though can be mitigated with reasonable testing. Updating to a new kernel release does need a bit more care and tesrting though. I think the risk of *not* updating is higher than that of updating, providing you do test to some extent.

> companies will just stop using Linux in their products, starting with anything to do with government contracts,

Unlikely I think. At this point is there are few viable alternatives to Linux for vast swathes of applications. The alternatives generally either aren't open source and involve per instance license fees (making them either insufficiently flexible or too expensive) or lack the breadth of hardware support that Linux enjoys (making them unusable for many, partiuclarly in embedded).