The advantages are there:
1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers.
2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service.
3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization.
4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.
At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.
So Oauth2/OIDC is what you typically want?
I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.
But it's also easy to understand what there is to be scared about:
1. Security critical.
2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. )
3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation.
It's not an area you can "fake it 'til you make it" or "move fast and break things" with.
Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.
If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.
Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party.
Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical.
On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated.
Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.