The bug level or not of CentOS was not its selling point, but compatibility:
> Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®.
* https://en.wikipedia.org/wiki/Bug_compatibility
If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you.
If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case.
What am I missing?
Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes.
And even these changes may need to be triaged to determine if the updates are even worth risking uptime.
One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.
From RedHat's announcement blog and Centos website: CentOS Stream "a continuously delivered distribution that tracks just ahead of Red Hat Enterprise Linux".
And indeed, I have read that all packages currently going into Stream 8 follow exactly the same testing and validation procedures than for entering Redhat Proper.
But of course, this holds true only for released RedHat versions. Meaning that Stream 8, is currently just ahead of RedHat 8.5 and will soon start to incorporate changes planned for 8.6 (so nothing like a "bleeding-edge test environment to test new changes" as you put it).
As for Stream 9 which was release recently, it is indeed the stabilisation socle based on fedora 34 that will eventually become RedHat 9. Once RedHat 9 released, Stream 9 branch will be stabilized and once again be "just ahead" of the impending RedHat 9 rpms.
In any case, I am not sure that hospitals should be running/updating self supported OS on surgical equipments without proper testing anyway.
Stream 9 is currently tracking RHEL 9.0, it shifted from the 9.0 Beta back around August. As we approach the ~May release for RHEL 9.0 GA, Stream 9 will start tracking RHEL 9.1 changes.
A key difference between Stream 8 and Stream 9 is the way the distribution is built. Stream 8 is a technically another rebuild project by the CentOS team, but one that rebuilds newer branch packages from RHEL engineering. In Stream 9, RHEL engineers are doing the builds themselves and are directly involved in the entire process.
There's a possibility that Stream 8 may adopt the Stream 9 workflow, but I'm not certain. With an EOL of 2024, it might not be considered a priority.
And I'd probably describe it as less of a "bleeding-edge" rolling release, more a "boring-edge" rolling release. Yes it's a rolling release, but packages are going in as a final shakedown before release into RHEL, so it's really quite far away from experimental.
And I've not really noticed any material difference from pre-stream. I'm still able to use my CentOS boxes in the same way as I did before - in some cases as build boxes for things to be deployed onto RHEL boxes.
(And, to be honest, those example use cases are probably places where I would be seeking to use a commercially supported distribution, rather than a community supported one. Albeit a community supported distribution that copies/replicates a commercially supported distribution.)
Here's an example: about a half year ago the host of linuxunplugged.com (a pretty popular podcast IMO) invited representatives both from Alma Linux and from Rocky Linux. The Alma guy was happy to be on the show and showed up a few hours before it started to chat with community members. The Rocky guy asked if any other distributions will be there, and then sent a passive-aggressive email where he declined to participate because "we're not interested in being compared against other distributions", or something to that extent.
This small example pretty much sums up their entire attitude.
FWIW, I've been using https://almalinux.org for the past few months on a couple of dozen servers and it's been smooth sailing.
(I've also been using Oracle Linux and it too worked fine. If only it were not Oracle…)