I think the root cause of insecurity here is the near-universal attempt to use general-purpose XML libraries to build SAML. When the Go instability bugs were announced, I think there was a general take from the Go community that `encoding/xml` was not an appropriate foundation for SAML libraries, and, in this instance, I think the Go community was right: I think it should have been self-evident that you couldn't safely build SAML on `encoding/xml` (it doesn't even really handle namespaces!)
When I did my own SAML in Go at my last job, I wrote my own soup-to-nuts XML, including DSIG canonicalization. It was annoying, but you can't get SAML wrong; you need to be able to predict what every component in the system is going to do. What makes this worse is that most SAML systems defer the cryptographic stuff to libxml/xmlsec; for obvious reasons, some of them sane, nobody wants to implement DSIG themselves. But then they interpret the signed message in a general-purpose XML library, and now you have competing XMLs in a single system. It's bananas.
In the esoterica of DSIG, there are even worse problems. DSIG is a very flexible format; it has has pluggable canonicalizations, happily supports multiple signed subtrees under different keys in the same parent message, and supports both detached and embedded signatures. There's a famous, respawning DSIG bug where you can trick validators into verifying a signature on one subtree but passing on a different subtree to the calling application. A researcher at Duo Security tricked SAML implementations by embedding comments in text fields, which, after canonicalization, tricked parsers into returning altered text fields. Technically, SAML responses are supposed to be strictly schema-validated, so you can't sneak arbitrary subtrees into the middle of a SAML response --- but there's at least one extension field in a SAML message that has an any-typed free-form tag.
It's also worth remembering that SAML's problem domain is difficult even setting the XML part of this aside. It's pretty common to find very bad authorization vulnerabilities in multitenant SAML RPs, because you have to check mesaages carefully beyond their signatures. Many of the high-level OAuth2 protocol issues port over to SAML as well. It's tricky to audit!
People stick up for SAML because what it does (facilitating centralized SSO) is extremely valuable; it's probably more valuable than the bugs are harmful, as long as you're using well-known tools that people have already been incentivized to scrape for SAML vulnerabilities. If I was adding SAML support to something new, I'd consider beyond all the standard SAML checks also rejecting any message that doesn't have the same shape as what Okta, Onelogin, Google, or Shib generates.
But if you have the option, I'd also say avoid SAML.