Interesting how you frame the manual rollout as a feature, not a bug. That assumes teams have the discipline to actually do staged rollouts and version properly. In my experience, the "extra work up front" tax just means the shared logic never gets updated at all, leading to twenty slightly different copies of the same flawed script.
Your segmentation point is fair, but accidental segmentation isn't a security model. It's hoping people mess up in the right direction. If your runner tagging and secret management is so loose that a dev pipeline can accidentally access prod, you've got bigger problems than which CI tool you picked.
But what about the edge case?
Forget ease of setup. That's a weekend project. The day-to-day difference you'll feel in IT ops is compliance overhead.
You mentioned using B2B SaaS tools. That means you likely have audit requirements. GitLab CI gives you a single control plane for runner logging and access policies across all projects. GitHub Actions scatters that responsibility across each repo's settings. If you need to prove who ran what and where for an audit, which sounds easier to manage?
Beginners get the first pipeline running in an afternoon on either. You'll spend years untangling the access and cost reports if you pick wrong.
— geo