CentOS 8 was released few days ago with kernel 4.18, which not even LTS is, and is older than the current Debian stable kernel(!).
If you need to install anything besides the base distro you need elrepo, epel, etc which I'm not sure can be counted as part of the support.
This means that RHEL 7 using a "kernel version" from 2014 will still work fine with modern hardware for which drivers didn't even exist in 2014.
And for the same reasons that the affected users chose a "stable" and "supported" distro they were also unable to upgrade to one where the issue was fixed.
They bought some fancy new computers at work. Our procedures say to use CentOS 7, so we tried it, it ran like shit. Then we reinstalled CentOS 8, same. It worked, but the desktop was extremely slow. After much hair pulling I found the solution: add the elrepo-kernel repository, and update to kernel 5.x
No amount of backporting magic will make an old kernel work like a new kernel.
If your use case doesn't consider avoiding noncritical behaviour changes for a decade to be a feature, you have other options.
People that run CentOS in prod are normally running ERP systems, Databases, LoB Apps, etc, and the only thing we need is the base distro and the the vendor binaries for what ever is service/app that needs to be installed, and probably an old ass version is JDK...
We need every bit of that 10 year life cycle, and we glad that we will probably only have to rebuild these systems 2 or 3 times in our career before we pass the torch to the next unlucky SOB that has to support an application that was written before we were born...
that is CentOS Administration ;)
I always wonder how many major vulnerabilities are introduced into these super old distros due to backporting bugs.
[1]: https://old.reddit.com/r/netsec/comments/ch86o6/vlc_security...
Software are always gonna have bugs, it's written by humans after all. The important thing is to acknowledge and work towards an ideal outcome.
It also helps that Red Hat employs a lot of core developers for those fast moving packages. :)
Plus, there are changes (especially around memory management or scheduling) that are fiendishly hard to do regression testing on, so they are backported more selectively.