Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you would likely end up with a lot of failed attempts to sign up with some "3rd world" provider.
PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!)
The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found an identity provider yet that wouldn’t support that. Yes, that protocol has way too many knobs providers can fiddle with. But it’s absolutely doable.
I didn't say it was impossible, just impractical and that is why majority of services that use SSO only support google, apple, twitter or facebook. You write the code specific to these few providers once and are done with it for good. There is little reason to invest time and money for adding generic support for other providers. It's just the way it is. If OIDC protocol would get streamlined a bit, we could easily have universal support. But then again, these big providers would likely be stuck in the current version and not bother adjusting to the new, simpler version, if it would come to be.
With metadata endpoint, things become much easier, that is true.
Though how would you implement it? Like, user comes to your website and wants to sign in with some foo.bar provider, do you force the user to paste in the domain where you go look for the metadata? What about facebook or google, do you give them special treatment with prepared buttons or do you force user to still put in their domains? What about people using your flow to "ddos" some random domain...?
Fedcm offers some hope here, where the browser gets some capability to announce the federation domains to the RP. It's not straightforward though, of course. In this case though it's inverted - you are providing the url of the MCP server, and the MCP server is providing the url of an authz server it supports. The client is uses the metadata lookup to know if it should include PKCE bits or not.
PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.