It's been over 2 years since I dealt with it, but in essence the details boiled down to much bigger size limits for SAML assertions vs. how big a JWT token could be passed to AWS STS for AssumeRole call. 100000 characters of base64 vs few kilobytes of JWT, an error we hit very very early.

Also, for practical purposes, you can parse available roles out of SAML2 response from IdP, presenting a menu to the user asking them to select the right role.

To deal with OIDC having way smaller space for "assertions", I ended up adding extra parameters to OIDC login request, and modified our IdP (keycloak) to parse it and filter user's groups (set from AD) to only include the group passed in parameter. This way we could always "fit" inside OIDC token limits in STS.

This was in regulated environment where users had to be given very fine grained access, and simultaneously could have many, many, many roles available - and had to be able to switch between them at runtime. I think we blew the STS the moment we fed the IdP with real group membership dataset instead of the less than 10 groups we had used in tests. Don't recall if it also didn't trigger some really hilarious errors that I recall seeing, like Sagemaker exploding with EC2 ENI attachment errors, but that one could have been triggered by something else.