S/MIME is not password-based.
(In fact, it is theoretically possible to do password-based encryption of emails using the S/MIME format, which is based on CMS, which supports password-based encryption, but I strongly doubt that there is an email software out there who is able to process that, let alone produce it. In practice, no password.)
S/MIME relies on X.509 certificates: the recipient has a public/private-key pair; the public key is made public (as the name says) as part of an X.509 certificate; the sender uses the certificate to learn (with some guarantee of ownership) the recipient's public key; the sender encrypts the email with the recipient's public key; the recipient uses his private key to decrypt the email. That's for encryption. For signatures, a similar process occurs, this time with the sender's own private key (to generate the signature) and public key (the recipient uses it to verify the signature).
If passwords are involved, then this will be indirectly, for private key storage. Private keys are where the power is. The user's private key is what enables him to decrypt incoming emails and sign outgoing emails. Stealing the private key of a user means stealing his power. So private keys must be well protected. In the whole S/MIME system, private keys do not travel, but we know that files on a given machine can sometimes be plundered (malware does that), so we prefer it when there is some extra layer of protection like, say, a password-based encryption.
In that sense, the password alone does not give much to the attacker; he still must access the actual storage space for the private key in order to recover the private key, which is his true target. At that point, things vary a lot depending on the situation. For instance, in an Active Directory world, when the users' machines are part of a domain, knowing the password for one user and talking to the AD server is sufficient to recover the user's roaming profile, which contains his private keys. Moreover, since a domain administrator can, on the AD server, reset the password of any user, then it follows that gaining administrator's privileges on that AD server is also sufficient to recover the user's private keys, even without knowing the user's actual password.
An additional point about S/MIME and encryption in a business setup: presumably, encrypted emails are for business, thus contain business data. Correspondingly, losing access to a private key implies losing the data. This happens, for instance, if a user becomes "unavailable" (he was fired, he was ran over by a bus, he ate bad clams...). The employee who replaces him must be able to read the stored emails of his predecessor, and this requires some sort of escrow system. The fact that a Domain Admin can reset a user's password and recover his private keys is thus not a weakness; it is a necessary feature. However, any key escrowing system like this one can become an additional entry path for an attacker.