OAuth 2.0 basically killed generic identity providers leaving us with a hand full of SSO providers you can use.
It also instead of a simple generic OAuth 2.0 library we had (and still have) separate libraries for the various OAuth SSO providers. Through this has converged a bit since the initial days. But the initial days where enough to cause harm to the ecosystem.
It also needs a variety of "extensions" you have to add to make it secure. But which can slightly differ between SSO providers. (Note sure but I thing some of this "extensions" have been added to the spec retrospectively.)
In conclusion I would say while OAuth 2.0 is widely used it also was widely harmful and lead to a further centralization and to users being more dependent on a few mega corporations.
In this context it has fully failed some of the initial ideas people had about it when it's design started.
Just because something is widely used doesn't mean it's not harmful or well designed. Adaptation of technology is often not driven by what is the technological best solution especially wrt. web technology.
You may have heard the aphorism, "All problems in computer science can be solved by another level of indirection." This, or some variation of it, is known as the fundamental theorem of software engineering, variously attributed to Andrew Koenig, Butler Lampson, and David J. Wheeler.
With oauth2, literally any sort of authorization (or, in theory, authentication) is possible, but first you have to ask some endpoint for the details. In the case of oauth2, the core concept for authorization is "scope", but nothing is prescribed in scopes. They can literally be anything the auth provider describes. In theory, it's not supposed to matter – a consumer is just supposed to be able to pass around scopes from providers and let them determine if access is allowed. In practice, there's no practical way to reason about scope+resource permssions.
Oh, and despite the name, oauth2 is not about authentication, it's only about authorization. The OIDC spec, built on oauth2, provides authentication services, but again, there's no spec. Every auth provider does what it wants.
It's sometimes said that oauth2 is great for consultants, because any organization wanting to deal with it must hire (or contract with) specialist who can sort out the ill-defined problem space.
Although personally i don't think its a great spec. Its a good enough spec (certainly better than saml, shudder) - "good" is not the same as works acceptably or popular.
After extensive experience with SAML and other specs, I don't think it's better than SAML in a fundamental way. It's certainly better in that it doesn't require a mind-numbingly verbose blob of XML, but strip away the XML and all that verbosity, and you basically end up with... kerberos.
