See "Q: Why was CentOS Stream created?", it is no longer rebranded RHEL with the same stability, but something akin to regular Ubuntu releases vs Ubuntu LTS.
No, it isn't. It's far more similar to Ubuntu LTS than to regular Ubuntu releases. All it is is an LTS distro without explicit .Y or .Y.Z releases
CentOS Stream is no more than "roughly what RHEL will look like when the next maintenance release comes out 0-to-6 months from now". That is not remotely true of the regular Ubuntu releases.
Regular Ubuntu releases (like 20.10, 21.04) have no compatibility guarantees with each other or with Ubuntu LTS. They have major version upgrades for kernel, systemd, glibc and other major packages, they change APIs, they change ABIs, etc.
CentOS Stream, like RHEL and Ubuntu LTS, does not do this, because it's the upstream for RHEL X.Y+1, and RHEL X.Y+1 is intended to be ABI-identical and functionally compatible with RHEL X.Y. Therefore nothing lands in CentOS Stream which would break the stability promises of RHEL maintenance updates, at least not intentionally.
The stability promises are the exact same. The part that caused so much frustration in the community was not this, it was that CentOS is no longer attempting to be "bug-for-bug compatible" with RHEL. And that is because instead of bugfixes going through QA and then landing on an internal nightly RHEL tree, instead they go through the exact same QA processes and then land in a public CentOS Stream tree.
So CentOS Stream gets bugfixes (except for embargo-d security patches) and the occasional feature prior to RHEL, but the QA is the same, and the stability promises are the same.
> See "Q: Why was CentOS Stream created?"
This does not say anything which backs up the statement you made.
> The part that caused so much frustration in the community was not this, it was that CentOS is no longer attempting to be "bug-for-bug compatible" with RHEL.
But that's my point (albeit perhaps not made as well as it could be): previously you'd tell your clients that they need RHEL version X.Y, or CentOS version X.Y or Oracle Linux version X.Y (or whatever) for the software that you want to deliver, against which version it has been tested, they'd install it in their VM/bare metal server and you'd have very few issues until EOL would roll around (admittedly i've run into a few issues like xrdp randomly breaking after an update, but that's not as important here).
Having support for roughly 10 years was pretty much a life saver in an enterprise setting that wouldn't update major releases too often and would rather focus on shipping features, CentOS 7 is supported from 2014 to 2024, CentOS 8 should have been supported for a similar amount of time, were it not for the project being "changed" like it was thanks to Stream. I am yet to see people talk of Stream in a positive context or offer it in most (regional) cloud platforms, some have switched to Oracle Linux instead, some are looking into Rocky Linux, the people who paid for RHEL simply keep paying for RHEL. Of course, that's just my subjective experience so far, i personally prefer DEB or just run containers, so i don't care too much.
For many Stream won't be an issue, but for others its akin to running their software on JDK 18, 19, ... instead of JDK 17 which is the current LTS offering. Ubuntu remains similarly boring as it previously has, you can run your software on 20.04 for the years to come with few surprises. CentOS Stream sitting between RHEL and Fedora is a non-starter for many.
Of course, Red Hat can do whatever they feel is good for the project long term or what makes sense financially, the people who are not okay with it will simply look elsewhere. Thankfully, containers let you lessen the headache by quite a lot.
CentOS Stream is still an LTS distro. Releases get 5 years of active support, the same as Ubuntu LTS, Debian and OpenSUSE Leap.