It's easy. You gather information about what the risks and hazards are for each vulnerability and then pragmatically decide whether there are any unacceptable risks after you mitigate with other layers of security.

It's a really common engineering task to do this and I'm not at all surprised that someone trying to maintain uptime would do so. Honestly it's more mature than updating every time because each change also introduces more potential for regression. If your goal is to run a stable system you want to avoid this unless the risk is outweighed.

But with "yum check-update" or the equivalent apt-get incantation saying you have dozens of security updates every week or two, reading the release notes for all of them and deciding which ones can be skipped safely in your environment is too much work. Far easier to just apply all updates every two weeks or monthly or whatever your schedule is, and then reboot.

Fully agree here; a lot (most?) of patches and updates are simply not exploitable in the respective server use case, so why should I incur risk of downtime to apply it?

you willfully ignore kernel security updates.

If my system is closed to the public world, has a tiny amount of external services, and I am aware of the specific bug delta since system release and what mitigations may or may not be required, I can leave it running as long as I choose to accept the risk. Cute phrases like 'pattern' and 'anti-pattern' are rules of thumb, not absolute truths.

Ksplice or KernelCare

Kernel Live Patching (KLP) has been in mainline since 4.4. I've used it to patch various flaws in my Linux distribution since rebooting the running cluster is more tedious.

kexec?

kexec doesn't keep your services running, it just allows the kernel to act as a bootloader for another kernel.