However, running a high availability auth service isn't in the core skills of every software team, and therefore folks want to outsource it. That way the teams can focus on building and running the software that is core to their business.
On the other hand, some folks have teams and processes to run a service like auth at a high level of reliability. In this case, using OSS options like Shibboleth and Keycloak makes a lot of sense. At FusionAuth, we see customers migrate from those systems because they want something more modern with a team releasing new features (with their feedback). OSS has some fiddly parts, and knowing who to ask for support can be tough (though there are contractors out there who can help).
It's not a trivial choice. As mentioned in the article there's a fair amount of lock-in. The lock-in is both technical (if you build features on top of non-standard parts of an auth server) and organizational (once you have a working auth system, you aren't going to get a ton of new features if you move), which is why Okta has negative churn (as reported in their earnings).
But if you build to OIDC and put facades around the provider, you should be able to migrate (make sure you can get your password hashes as well as other data).
tl;dr: it depends :)