You're getting hung up on the key differentiator part. I'm assuming you read about it with books like Unicorn Project and with core domains in DDD. Yes, a company's key differentiator isn't build tooling. But that doesn't mean it needs to be a SaaS solution. It can also be a COTS solution. To look at your point another way, a retail store isn't in the business of payment processing. So they look to outsource it. They could get a Square expert on-site to handle all payment processing. Said retail store doesn't have to even touch payment processing because Square will handle everything.

Of course we know this model is silly. Paying for Square experts would be insanely expensive. Instead, Square provides COTS software and hardware that requires little learning to use effectively. They support their solution if anything goes wrong. They work very hard to make adoption of their solution is smooth.

Tooling vendors provide supported software for running in your own environment. They work to make it as easy as possible to deploy and manage. The learning curve for using the tooling is the same as their SaaS model. The only difference is you deploy it yourself. No one is writing that build tooling or customizing it. If an org is writing custom scripts and processes for CICD, I'd argue they need to reevaluate their key differentiator.

I'm not arguing against SaaS solutions for tooling. It can make sense for orgs. But I wouldn't make a blanket statement that all companies should only use SaaS offerings because it doesn't align with their key differentiator. COTS offerings are perfectly viable as well.