Yes, that is the question that we get asked, a lot... so what is the answer to it?
First of all it is not just about SAML. SAML is a federated Web SSO protocol just like OpenID Connect or WS-Federation and any arguments for SAML would apply equally to any of the other protocols. Moreover, federated SSO protocols are token-based in nature, e.g. they use tokens to sign on users to applications instead of passwords. Thus any arguments in favor of SAML would apply equally to token-based protocols that have goals that are different from Web SSO, such as OAuth 2.0 or WS-Trust that focus on protecting APIs with tokens instead of passwords.
So actually the question should be: "why are tokens more secure than passwords"? Well, that boils down to two core characteristics of tokens:
Scope limited: tokens are issued for a specific usage, e.g. for a specific target or application; moreover, they may even represent a constrained set of permissions within a single application (e.g. read or write).
Time restricted: tokens expire, e.g. are valid only for a limited amount of time.
As you can see passwords have far worse characteristics: they are unrestricted in time and give the software that uses the password access to anything that the user can access, possibly across different targets or applications. With these characteristics in mind it is not difficult to list the benefits of federated SSO tokens over passwords:
Mitigate password proliferation: no longer are passwords stored across multiple 3rd party/SaaS apps. When the next SaaS breach happens it will only affect that specific SaaS and you won't have lost a password that can be used elsewhere as well.
Strong authentication: the Identity Provider can upgrade to stronger (e.g. multi-factor) authentication independent of the applications yet the (SaaS) applications still benefit from that upgrade.
Granularity: tokens allow for granular application permissions instead of granting access to everything that the user has access to possibly across other targets or applications.
Revocation: tokens can be easily revoked or renewed whereas passwords are much harder to revoke or change (without breaking other stuff)
Differentiation: a token can be issued for a specific client and so it allows the application to distinghuish between that client and the user himself, which aids to auditability and compliancy.
Teaches users to be more careful with their (single) password: as users have less passwords now, the one(s) that they still have - with their IDP(s) - are more valuable to them.
These basic security benefits also give rise to a number of higer-level business-related benefits:
Lower overhead of managing user credentials: only at the IDP
Less liability: better compliance with laws, regulations and standards
Less identity thefts
Increased protection of Personally Identifiable Information (PII)
So back to the original question: as you can see it is not an either/or question and it only makes sense when you consider it from a particular point-of-view, i.e. the application provider, or the user, etc. In 99% of cases, passwords will continue to play a part in an identity architecture. SAML can help you make your architecture more secure if you use it to isolate and control where and when passwords are used and for the reasons listed above. But SAML cannot replace all passwords - examples include administrator credentials, client bootstrapping credentials, and usually the primary authentication mechanism.