This only happens on poorly thought pipelines and GitHub actions model or Jenkins high level directives won't make up for it. Eventually it'll break.

In Gitlab you can use the main file for describing high level stage pathways (tests, builds, deployments...) and offload individual control of jobs to granular files. Tests can be self contained child pipelines. Templates make them easy to replicate and components give them more flexibility.

You can do a lot more than GitHub actions with a lot less complexity than Jenkins.

I was responsible for administering a self hosted GitLab instance for a medium sized company and our backups never required downtime. The built in backup command doesn't require downtime but also isn't a consistent point in time snapshot (specifically because the instance keeps running while the backup is being taken). If they've decided they need one for some reason, stopping GitLab is certainly the easiest way, but not the only way of accomplishing that goal, but that'll be true of any self-hosted forge, including GitHub.

Weird. I’ve been on a self hosted enterprise gitlab and I think we’ve have only one or two performance degradations/outages in the past 6 years

If the repos are public, hosting location doesn't make a difference.

We're going to need something more expansive than OSI software licenses for the future.

Something like, "if you look at us, we must be able to look at you"

What makes it more complicated than doing a Git push against two remotes? Assuming that one of those is used for collaboration and the other is just a mirror.