saml has annoyances, but it doesn't have so many annoyances that every customer needs to be a custom integration. the majority of users using saml are going to be coming from a handful of idps, typically adfs or google.
I am also from a SaaS vendor and we are using a 3rd party to integrate to the various SSO providers our customers have. We have not tacked on any additional cost to our customers for this as we also believe this to be baseline. But I do like the approach of at least covering costs.
For us it was not a matter of "not being bothered to implement saml in-house". We carefully considered our options. However, implementing it ourselves means we must have an in house expert on SAML and understanding the various IDPs.
It also requires someone to tightly monitoring any security issues that may appear in the wild that could impact our implementation. (We do still need to keep our eyes open, but we can leverage our vendor for help here.)
Resources required to this ourselves is a minimum of at least 1 full time engineer and someone who can be their backup, we need additional testing resources, and more. Making this roll < full time will hurt you down the road.
I'd rather our people can be focused on the problems our product is built to solve for our customers and then we can work with experts in the SSO space to guide / help us in solving that problem.
On the other hand: the 3rd party we're working with likes to come back every few months with a "Oh! We didn't know you were going to do (fill in the blank), we need to add another dollar per user per month for that."
Neither approach is perfect. But I lean towards keeping our teams as focused as possible on our product.
(PS: I have been with other orgs who've done SAML in house, and it is not simple. Don't underestimate it. It hurt, and we burned a lot of resources that could of been making our product better.)