A useful framework for thinking about SAML vs OAuth from an engineer's perspective is to think of OAuth as class based, while SAML is instance based.
When you set up a new OAuth provider such as Github you typically grab a Client ID and Secret, specify your redirect URIs, and once your integration is complete any Github user can sign in with a Sign in with Github button.
But with SAML, you need to perform configuration with each customer's Identity Provider instance. As you pull on this thread you start to see where the challenge with SAML lies. SAML as a protocol isn't super complicated, and tons of OSS already exists to perform authentication. But you need to create and persist configuration data for each of your customers, which suggests needing a UI to perform this onboarding. You need to help your customer configure your app in their IDP, so you'll want to create documentation. And you need to adjust your sign in flow - you can't just stick a Sign in With Okta button, you need to ascertain from the user which IDP they use for authentication.
Osso though handles all of the "instance based" challenges, and allows your app to use OAuth to communicate with your Osso instance.