There's a wealth of issues, some generic and some specific to the (not so well thought out...) choices made by the SAML spec.
For starters, the XML signature spec requires canonicalization of the message (which is XML). But the message itself need not be the canonicalized message. So the SAML implementer, if they follow the spec, must process the untrusted input and canonicalize it prior to verifying the signature.
Add in that you can override just about every aspect of the signature algorithm, canonicalization details, and even what parts of the message are actually signed, and you get huge number of places where things can either go wrong or may be overlooked.
Then throw in "XML Encryption" (again with canonicalization) which could be done on the whole message or just the assertions.
Then throw in that you can sign the encrypted portion, or the unencrypted portion, or just the assertions, or encrypt the signatures, or ...
So in short, there's too many ways to do too many thing.
Which leads to a massive surface area of code if you actually follow the spec. Which leads to libraries that either do not follow the spec (e.g., ignoring encryption and just checking signatures in a known ___location), or think that they follow the spec but will happily ignore missing assertions or out of date certificates.
SAML sucks. But hey, it's still better than having your own passwords!
There's also detached signatures and flexible tag matching, which lead to implementations that have provide rigid schemas with semantic passes to make sure there's no place to smuggle either additional signed content to confuse verifiers, or content that will get signed that changes the message semantics. The whole thing is deeply unsound. OIDC is no great shakes, but even 10 years ago nobody would ever design a signed message scheme that looked like SAML.
Outdated certificates are actually fine with regards to SAML, oddly enough; the logic being that the trust is handled out of band at metadata level, and the certificate is just a public-key distribution method. (That applies to Shibboleth at least; other implementations may disagree.) This does of course assume that you have a means of safely keeping metadata for the other end of the trust relationship up to date. In an eduGAIN/local federation setting, that's easy enough to do with signed XML metadata feeds and daily fetches, but far less so for bilateral trust.
The XMLDSig stuff is definitely a mess though. There were definitely issues with comments in signed content allowing values to be truncated to the start of the comment, along with some similar weirdness with XML entities. And that's before any of your (entirely valid!) complaints...
There's a wealth of issues, some generic and some specific to the (not so well thought out...) choices made by the SAML spec.
For starters, the XML signature spec requires canonicalization of the message (which is XML). But the message itself need not be the canonicalized message. So the SAML implementer, if they follow the spec, must process the untrusted input and canonicalize it prior to verifying the signature.
Add in that you can override just about every aspect of the signature algorithm, canonicalization details, and even what parts of the message are actually signed, and you get huge number of places where things can either go wrong or may be overlooked.
Then throw in "XML Encryption" (again with canonicalization) which could be done on the whole message or just the assertions.
Then throw in that you can sign the encrypted portion, or the unencrypted portion, or just the assertions, or encrypt the signatures, or ...
So in short, there's too many ways to do too many thing.
Which leads to a massive surface area of code if you actually follow the spec. Which leads to libraries that either do not follow the spec (e.g., ignoring encryption and just checking signatures in a known ___location), or think that they follow the spec but will happily ignore missing assertions or out of date certificates.
SAML sucks. But hey, it's still better than having your own passwords!