In a previous life doing consulting, I worked for a shop whose owner was a Red Hat certified engineer. Our servers ran Red Hat. Our customers bought Red Hat. We were trained on being able to evaluate a system based on the checksums of its RPMs and determine system health from it. The boss was a real Type-A guy who clearly derived deep, spiritual satisfaction from the idea of being able to conclusively, systematically test and prove that his servers were running, say, RHEL 4. Period, full-stop. The RPMs are RHEL 4 RPMs, therefore this is a RHEL 4 machine. Quod erat demonstrandum.
Eventually, we took on a customer who ran Debian, a nearly alien system to us. One of our engineers was experienced with Debian and I still remember the conversation he had with the boss explaining that Debian repos aren't segregated into "packages that were shipped on day one" and "patched packages" the way Red Hat worked. A Debian machine is a collection of the packages its installed, from whichever release branch its admin has chosen, with the option to select some things from sarge and other things from woody if one is willing to try. The idea that it was possible, and even easy, to take a sarge machine and make it somehow not a sarge machine but also not some other rigorously-defined thing, and that that was just something Debian users did, was so foreign to the boss that he buried his shocked expression into his hands and screamed one of those deep, primal screams that you only hear when a little-endian finds out someone is eating their egg wrong and getting away with it.
Further back, in the even older olden days, your operating system came on a CD-ROM or perhaps a stack of floppy diskettes and any kind of upgrade to the OS was going to involve buying another CD-ROM or stack of floppies. If your system had a bug you were stuck with it until the next service pack was released, and that might be a year away, not counting the time it would take to get your hands on the physical media to install it. Sometime around Windows 98 Microsoft started allowing users to download patches directly to their systems through a website, but I wouldn't consider Windows "semi-rolling" even today when you can, in theory, patch a Windows 10 machine to Windows 11 through the Windows Update utility if they bless the hardware.
The fact that OSes like Debian, MX, and Windows even have numbered releases is a good indication they aren't to be considered rolling. There is no "Arch 12" or "Void Linux 6.5" in large part because those projects are structured to not have a clear, exact definition of what constitutes a release. In professional software development this idea of having a period, full-stop, we-gave-it-a-special-name-and-everything Release Version is known as RTM (Release To Manufacturing[0]) or "going gold"/"golden bits". Some people love this idea for its concreteness even though system software invariably ages and becomes insecure over time. People like my old boss, for example.
All of this is context for the fact that I'm still trying to reconcile OP's conflicting statements of "I like rolling releases" and "I don't like too many updates".
[0] This is a throwback to the days when you still had to write your software to physical media, which meant mailing something to a factory to have them make your CD-ROMs or floppies for you and put them into boxes with your logo on it. The distribution process has changed but the term persists. This is also why some people still use the term "shipping" in software, as in "Looks good. Ship it.", meaning you've entirely completed the task of making the software and now it's someone else's responsibility to get it into stores and onto retailers' shelves.
