https://swagger.io/docs/specification/authentication/openid-...
The only reason an authorisation server would support dynamic client registration, however, is because it's meant to be pluggable as the back-end for an API integration suite like Kong Enterprise.
The solutions that are one big well-known IdP have no reason to want it, so Google Auth, Amazon Cognito, and similar all don't support it.
The solutions that are aimed at letting organisations be an IdP do have reason to offer it: it makes being an IdP easier, because you can stand up a client registration service without using vendor-specific interfaces.
No-one who operates an IdP wants arbitrary, uncontrolled public client registration. It'll get abused directly, and it'll enable further abuse of the systems the IdP is meant to protect.
SAML is too limited to compete with OIDC/OAuth2 on the web, but it's got some advantages for enterprise authentication, so it won't be going anywhere.
Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all those implementation-dependent details of how you're supposed to talk to an OAuth IdP.
Compare/contrast: SAML. SAML binding a webapp to an arbitrary IdPs just by punching in the IdP's SAML config endpoint URL? Works perfectly.