Because SSO outside of the OAuth2 happy flow [0] can be a pain in the ass to develop for and support.
Some customers use Okta; great! But some of those customers have Okta configured in ways that don't work with your auth service. Some customers use Okta as a downstream to their _actual_ IdP, which could be Keycloak (a million different ways to configure that) or, god forbid, some custom thing they wrote. You've gotta support that.
Some customers (the ones that will pay the REALLY big bucks) use Active Directory Federated Services and SAML-based auth. SAML is XML/SOAP. Gigantic pain. Gotta support it.
Some customers want LDAP/LDAP-S based auth. Gotta support that.
Given all this, it makes much more financial sense to lock that behind customers who are willing to pay the big dollars for enterprise-y features AND support instead of dealing with infinitely long support tickets.
[0] There is no such thing as a happy OAuth2 flow.
Some customers use Okta; great! But some of those customers have Okta configured in ways that don't work with your auth service. Some customers use Okta as a downstream to their _actual_ IdP, which could be Keycloak (a million different ways to configure that) or, god forbid, some custom thing they wrote. You've gotta support that.
Some customers (the ones that will pay the REALLY big bucks) use Active Directory Federated Services and SAML-based auth. SAML is XML/SOAP. Gigantic pain. Gotta support it.
Some customers want LDAP/LDAP-S based auth. Gotta support that.
Given all this, it makes much more financial sense to lock that behind customers who are willing to pay the big dollars for enterprise-y features AND support instead of dealing with infinitely long support tickets.
[0] There is no such thing as a happy OAuth2 flow.