In language package ecosystems (like Ruby's), you decide when to push out a new release. You find that updating your lockfile breaks your code, so you put it off. You push out a few versions without updating the deps. Then, in one release, you update them all, fix all the problems that introduces, and then push out a new version that has the new deps and works with them.

OS package management doesn't work this way, because, for the most part, for almost the entire history of OSes, developers have had no control over the environment their application is running under. In a lot of cases (enterprise IT; academic/HPC mainframes; PaaSes) someone else has an upgrade schedule for the OS packages, and you don't get any say on when it happens. The OS updates, your package breaks, your problem. You can maybe ask the ops department to hold off on updating, or have your PaaS "pin" your stack (until it becomes deprecated.) Either way, you're now vulnerable to security vulnerabilities while (hurriedly) working to push out the new release so that ops can get back to doing its job as normal.

LTS is a guarantee by the OS distributor that your ops staff can update any package at any time (from the LTS repos, at least), and such updates won't break your deployed custom software. So LTS solves the cases above: enterprise/academic/HPC/PaaS ops staff can just upgrade as they will, without worry that anyone will tell them to hold off.

But the value of LTS goes even further: if updates are guaranteed by the distributor to not break your runtime environment, then you can actually allow OS package upgrades to happen completely automatically and asynchronously to your development release schedule. The OS can just update itself. The OS distributor is now, themselves, part of your ops staff, ensuring that these updates aren't bothering anyone downstream of them. Your actual company doesn't have to care about the OS. It's always going to be secure, because it's going to update as soon as vulnerabilities are discovered+patched, and you can just deploy your code at your own pace without worry.

Now, mind you, this all might sound quaint to people who bake containers for everything and treat said containers' host OS as immutable infrastructure. For these people, OS package security vulnerabilities aren't really something you can let "fix itself"; they're something that requires baking a new version of your container-image, just as app library-dependency security vulnerabilities would be. Relying on OS services rather than bundling a copy into your container-image is a trade-off in this case: you don't get to pin the version of a dependency to ensure its exact behaviour, but in exchange, the distro will attempt to ensure that it will be free of security vulnerabilities while being pretty much the same version you started with.

(Oh, and as a side-benefit, usually LTS package updates don't force system reboots. Recently even kernel updates don't, with fancy ksplice-based patch distribution channels. So LTS releases also mean long individual-host uptimes, which is handy if you're running a service on the cheap and can't afford much horizontal scaling to manage load-balancing under rolling updates, but want five or more 9s of availability anyway. Try getting that using immutable-infrastructure reboot-to-update VM images.)