Except it's more complex than that.

Ideally you want to have multiple runners, and for them to scale so that developers aren't endlessly waiting in job queues. On top of that you might want proper network segregation, and for it to be on a separate virtual network to your workloads to reduce your blast radius. You might have problems with connecting your server to third party SaaS outside your network, etc etc etc

A runner is super simple to set up and you once write a script and just deploy it a few times.

Virtual network is also very easy to set up with most providers (even with dedicated servers), there's pretty much zero config.

So far we didn't have any issues connecting to outside SaaS, but we host most stuff ourselves anyway, so that's not a common use case.

I run Gitlab runners for my social group.. It took about 20 minutes to setup and I don't think there has ever been a maintenance period for it other than a nightly upgrade/restart that is automated. I use docker for network isolation.

There is 'running a basic linux server' then there is running a secure, scalable and reliable server for the whole org to use. The latter is the job of a sys admin, not an developer. Sure I could probably figure it out, but I am no expert and it would be a waste of my time.

It worries me that running a monolithic web application + DB on a Linux server is now seen as arcane, specialized knowledge. If you think this is complex, I'd be worried about how you do the actually complex stuff like data security, etc.

Engineers have to understand the business, talk with other stakeholders, design systems, write code, write tests, support the production environment, etc, etc, etc.

Why would decisionmakers want to add outsource-able ops overhead to that very full plate?

It probably depends what sort of software your company builds. A frontend web design shop might well have developers who have little or no relevant experience for self-hosting something like Gitlab.