Is there any reason for this other than key/certificate management on the client-side?
What is authentication ? That's making sure that whoever is at the other end of the tunnel is who you believe. It really depends on the kind of identity that you want to use.
For most Web sites, the interesting notion is continuity. They do not really care who is connected; indeed, the point of a Web site is to be readable by everybody. The kind of authenticity that a Web site wishes to achieve is to make sure that two successive requests are really from the same client (whoever that client may be). This is because the Web site experience is that of a logical succession of pages, driven by the user's actions (the links on which he clicks), and meddling with that movie-like framework is what the attacker is after. The user and the Web site designers think in terms of sessions and the attacker wants to hijack the session.
This authenticity is achieved by several mechanisms:
The cookie is sufficient to ensure continuity.
What extra value would client certificates add ? Well, not much. Certificates are a way to distribute key/name bindings. There are mostly three scenarios where client certificates (in a Web context) are relevant:
In the common case of a Web server, none of these scenarios apply. So client certificates are not used, because they would raise practical issues while not adding any extra value. That would be a solution in search of a problem.
In cases like Gmail, Yahoo and other web apps that use PKI to authenticate servers, client authentication is not done using certificates, but instead uses simpler authentication such as user/name passwords. Think about this. Your browser can store x number of certificates for the various CA's, and the websites out there. But can Gmail hold certificates for its millions of users ? It is simply not scalable.
This is a very simplified answer as to why client certificates are not used. However, when you SSH into a server, client certificates are/maybe used.
The client is trying to reach a specific server, identified in the URL. So the client needs to authenticate the server.
On the other hand, in most uses of HTTPS, any client can contact the server. The server doesn't have any prior knowledge of the client. So there is nothing for the server to authenticate the client against. The server wants to authenticate the user, not the client machine.
In an Internet setting, the client may be behind a proxy, on a dynamic IP address, etc. There is nothing that the server might want to verify. The only point of authenticating the client would be to record its identity for future uses, either for forensic purposes or to track clients across multiple connections. Since users may connect from multiple machines, there is not much point in tracking client machines. Recording client identities is only very marginally useful to identify malicious clients or users after the fact (the attacker is likely to have generated a certificate that doesn't provide any useful information), it isn't worth spending any effort.
In an intranet setting, where only known clients should connect to the server, client authentication is useful and is used.
The primary reason is that 95% of internet users have no idea what a client-side certificate is, let alone how to use one. Some users can barely manage to use usernames and passwords, and most still don't bother with two-factor authentication. It's also a hassle to install a client certificate on separate devices (desktop, laptop, tablet, smartphone, etc.) for authentication to a single service.
So, for a quick list:
So, whilst it would be nice to see client-side certificates on a large scale, I really don't see it happening unless a serious event pushes vendors into doing it.