The important part of the certificate is actually not the certificate itself, but the accompanying object called the private key. The "p12" file contains both. During the connection, the certificate (the public part) is shown to the server, and the private key is used to convince the server that the private key is indeed there (thus, presumably, the key owner, i.e. you). Technically, a digital signature is involved; this is handled within the mechanics of the SST/TLS protocol (that is used for every "https://" URL).
The main interest, for a bank, of using certificate-based client authentication is that your private key cannot be stolen with phishing. If evil people setup a fake Web site which really looks like the genuine bank site, they might induce you to enter your password in it, and then they learn your password; but they cannot steal your private key. That's the magic of cryptographic signatures: power to verify does not imply power to generate. Even if you foolishly connect to a fake server, and that server asks for a proof of possession of your private key (as per SSL), that won't allow the fake server to learn your private key and impersonate you.
So that's your upside: protection against phishing. Fake Web sites seem to be the most common Internet-related security threat for banks, so it is quite logical that they try to do something against it.
We may also argue that your private key won't be grabbed by a key logger, contrary to your password, but that's not a very good argument, because software key loggers can log keys only because they have some privileged access to your machine, at which point they can also grab or at least use the private key too. (The argument still works in the case of "hardware" key loggers, such as a camera concealed near the ceiling with a good view on the keyboard.)
There is another potential upside, but it is not really for you; it rather is for the bank. Distributing certificates to customers, within a specific procedure, can be the first step for signatures on transactions with non-repudiation. This is not something you get with SSL (where the signature is on the session, not on the transmitted data); it requires special code on the client side. Signatures with non-repudiation are a legal weapon against you, in case you use the Web site to send some financial transaction order, and then try to renege on it. The signature may then be used as proof, in court, that you really did it.
It is improbable that your bank uses such a signature system right now; but deploying client-side certificates is how it begins.