That was how it worked in the past, but it becomes frustrating because some changes result in many, many package rebuilds which hold up everyone else, or otherwise drains resources of the CI system, which would be better spent building existing packages. Staging is generally where changes that result in mass rebuilds go (or may introduce large instability) in order to keep the main branch "up to date".

Changes that are backwards incompatible (but do not result in mass rebuilds) can and will often just go to master directly. For example, NixOS module changes rarely result in mass rebuilds, even if it breaks an API -- but changing the default kernel version does. The latter would go to staging.

I exclusively use the unstable branch on all my Nix/NixOS machines. I rarely do rollbacks. But it's important to note that I'm a developer with commit access, so I can basically "just" fix things if they're problematic. Not everyone has that luxury. (Many Linux distro maintainers likely operate this way, I guess. :)

There have been events in the past where unstable has had changes that made rollback impossible. In particular, if the bootloader becomes unstable somehow, your rollback capabilities are toast (and you won't know until you reboot, when it's too late). But I don't think anything like that has happened in a long time...