1. Users are dumb
A password is something that fits in the memory of a user, and the user chooses it. Since authentication is about verifying the user physical identity remotely (from the point of view of the verifier), the user behavior is necessarily involved in the process -- however, passwords rely on the part of the user which is most notoriously mediocre at handling security, namely his brain. Users simply do not grasp what password entropy is about. I am not blaming them for that: this is a technical subject, a specialization, which cannot realistically become "common sense" any time soon. On the other hand, security of a physical token is much more "tangible" and average users can become quite good at it. Evolutionists would tell that humans have been positively selected for that for the last million years, because those who could not hold to their flint tools did not survive enough to have offspring.
Hollywood movies can be used as a model of how users think about passwords -- if only because those users go to movies, too. Invariably, the Arch Enemy has a short password and just loves to brag about it and distributes clues whenever he can. And, invariably, a British Secret Agent guesses the password in time to deactivate the fusion bomb which was planted under the Queen's favorite flower bed. Movies project a distorted, exaggerated reality, but they still represent the mental baseline on which average users operate: they envision passwords as providing security through being more "witty" than the attacker. And, invariably, most fail at it.
"Password strength" can be somewhat improved by mandatory rules (at least eight characters, at least two digits, at least one uppercase and one lowercase letter...) but those rules are seen as a burden by the users, and sometimes as an insufferable constraint on their innate freedom -- so the users become to fight the rules, with great creativity, beginning with the traditional writing down of password on a stick-up note. More often than not, password strengthening rules backfire that way.
On the other hand, user certificates imply a storage system, and if that system is a physical device that the user carries around with his house or car keys, then security relies (in part) on how well the average user manages the security of a physical object, and they usually do a good job at it. At least better than when it comes to choosing good password. So that's a big advantage of certificates.
2. Certificates use asymmetric cryptography
The "asymmetry" is about separating roles. With a password, whoever verifies the password knows at some point the password or a password-equivalent data (well, that's not entirely true in the case of PAKE protocols). With user certificates, the certificate is issued by a certification authority, who guarantees the link between a physical identity and a cryptographic public key. The verifier may be a distinct entity, and can verify such a link and use it to authenticate the user, without getting the ability to impersonate the user.
In a nutshell, this is the point of certificates: to separate those who define the user digital identity (i.e. the entity which does the mapping from the physical identity to the computer world) from those who authenticate users.
This opens the road to digital signatures which bring non-repudiation. This particularly interests banks which take financial orders from online customers: they need to authenticate customers (that's money we are talking about, a very serious matter) but they would love to have a convincing trace of the orders -- in the sense of: a judge would be convinced. With mere authentication, the bank gains some assurance that it is talking to the right customer, but it cannot prove it to third parties; the bank could build a fake connection transcript, so it is weaponless against a customer who claims to be framed by the bank itself. Digital signatures are not immediately available even if the user has a certificate; but if the user can use a certificate for authentication then most of the hard work has been done.
Also, passwords are inherently vulnerable to phishing attacks, whereas user certificates are not. Precisely because of asymmetry: the certificate usage never involves revealing any secret data to the peer, so an attacker impersonating the server cannot learn anything of value that way.
3. Certificates are complex
Deploying user certificates is complex, thus expensive:
Issuing and managing certificates is a full can of worm, as any PKI vendor can tell you (and, indeed, I do tell you). Especially the revocation management. PKI is about 5% cryptography and 95% procedures. It can be done, but not cheaply.
User certificates imply that users store their private key in some way, under their "exclusive access". This is done either in software (existing operating systems and/or Web browsers can do that) or using dedicated hardware, but both solutions have their own set of usability issues. The two main problems which will arise are 1) the user loses his key, and 2) an attacker obtains a copy of the key. Software storage makes key loss a plausible issue (at the mercy of a failed hard disk), and sharing the key between several systems (e.g. a desktop computer and an iPad) implies some manual operations which are unlikely to be well protected against attackers. Hardware tokens imply the whole messy business of device drivers, which may be even worse.
A user certificate implies relatively complex mathematical operations on the client side; this is not a problem for even an anemic Pentium II, but you will not be able to use certificates from some Javascript slapped within a generic Web site. Certificate requires active cooperation from client-side software, and said software tends to be, let's say, ergonomically suboptimal in that matter. Average users can normally learn to use client certificates for a HTTPS connection to a Web site, but at the cost of learning how to ignore the occasional warning popup, which makes them much more vulnerable to some attacks (e.g. active attacks where the attacker tries to feed them its own fake server certificate).
On the other hand, password-based authentication is really easy to integrate just about everywhere. It is equally easy to mess up, of course; but at least it does not necessarily involve some incompressible extra costs.
Summary
User certificates allow for a separation of roles which passwords cannot do. They do so at the expense of adding a horde of implementation and deployment issues, which make them expensive. However, passwords remain cheap by fitting in a human mind, which inherently implies low security. Security issues with passwords can be somewhat mitigated by some trickeries (up to an including PAKE protocols) and, most of all, by blaming the user in case of a problem (we know the average user cannot choose a secure password, but any mishap will still be his fault -- that's how banks do it).
