Particularly for systems that are installed as appliances in customer data-centers, where you as the vendor are both (a) responsible for the appliance as a whole to continue working but (b) have little / restricted access to continue maintaining it, RHEL helps you sign long multi-year support contracts for said appliance with the customer while keeping your maintenance costs to a minimum (since the cost of hiring more support engineers then flying them out is going to be higher than the RHEL license cost).
And I use RHELlikes (Alma/Rocky) in my homelab just cause its similar to Fedora and Red Hat's documentation is much better than reading random blogs on how to do stuff on Ubuntu/Debian.
I often hit it from search results (mostly for software made/supported by RHEL) and it works fine for Debian
Also, OS upgrades work
For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a purchased copy of RHEL for support reasons. And usually the ISV software costs many multiples of the cost of a RHEL license, so it's lost in the noise.
RHEL did ABI or kABI breaks only with minor releases. CentOS Stream can do them randomly, just like any other distribution.
That said, the CentOS Kmods SIG generates reports on how the kABI churns in CentOS Stream[1] and RHEL[2].
With minor releases you would read release notes, check your modules and knew, whether you can update or not.
Other distros also don't change kernel version during stable phase so I don't even know what you mean by that. Hell, RHEL kernels have more changes than say a Debian kernel over lifetime of a version.
What Red Hat uniquely does is to backport features into older version of the kernel, so statements like "you need kernel x.y.z for this to work" don't really apply, you need to find whether they backported that feature or not.
We've also experienced some "fun" with how they manage it and versions in general for example:
* Driver bug was backported from newer kernel (they backported "performance improvements" not bugs) in rhel5, so we lost VLANs on our upgrade canary * Same bug was backported to rhel6 with same disastrous result 6 months later * One of servers stopped booting because they changed version of LVM in STABLE DISTRO (think it was rhel6), and new LVM version deprecated/renamed some flag that we used, that made it fail on boot.
So yeah, we're very happy we migrated off it. And in Debian distro upgrade works too!
Clearly you've no idea what kABI means. This article (for Red Hat customers) explains it: https://access.redhat.com/solutions/444773
Edit: A different link which isn't paywalled: https://developers.redhat.com/blog/2018/03/28/analyzing-bina...
I agree with you that there is value in kABI stability, but this comment does nothing to convince others. Do you have a better freely accessible resource?
Not everyone (probably not many too) have experts that will track a kernel bug or know how some obscure interaction works.
If you have knowledgable people in-house the RHEL is essentially useless and WILL actively make your life harder compared to just installing Ubuntu or plain Debian as they like to mess up and segment software that normally would be in same repo... but if you don't, and "just need a software that happens to run on Linux", it's cheaper to pay for few servers than hire top level Linux expert.
When we used it many of the "wait, this doesn't work like in vanilla Linux" could be traced to some RHEL engineer changing stuff to work for their enterprise customers.
Like we had audit fail on too old SSH encryption modes enabled. The encryption modes that were disabled and deprecated in that version of SSH but Redhat brought it back with a patch, presumably to support some legacy environments of their customers.
They also do some utter mess with openssl, like removing a bunch of EC curves and various FIPS-related stuff of dubious security impact, re-adding sha1 support and bunch of other stuff
http://mirror.stream.centos.org/9-stream/BaseOS/source/tree/...
LTS is key because migrating OS and recalibrating everything is expensive as fuck for large organizations. As the amount of manhours needed to migrate everything, retest and retool everything and retain and update all your internal documentation is stupendous.
Also having real support for a product is worth its weight in gold in a corporate environment because it allows you to offload responsibilities when stuff breaks.
If 10% of your customers need this for compliance, then you have to test and certify that your stuff works with something like RHEL - and so that becomes an option, or even the default option for the other 90% of your customers.