As I understand it, a certificate is used only for verifying the identity of the server. Are there any security benefits for changing them frequently (once a week for example)?
If this is done so that a new symmetric key can be negotiated for each session (for perfect forward secrecy (PFS), say), can't it be done without needing to change the certificate? Am I misunderstanding how certificates are used?
Renewing the certificate has no benefit, except if you use it as a substitute for revocation. Normally, a certificate is issued by the CA for some time (say, one or two years); to cope with abnormal conditions (e.g. the private key was stolen), the CA will regularly publish a list of "revoked certificates". A revoked certificate which looks good cryptographically (it is properly signed and all), but must nonetheless be rejected because the CA says it so. Revocation status check entails downloading the current CRL, verifying its signature and looking at its contents; this is bulky and cumbersome, and a lot of SSL clients (say, Web browsers) are tempted not to download CRL. If the certificates are very short-lived, then not checking revocation status can be tolerated: the CA, presumably, would not renew a certificate that it would consider as revoked.
This is an edge case. Usually, it is considered that the overhead of renewing certificates every week outweighs the cost of publishing and processing a new CRL every week.
Renewing the private key may have benefits. Remember that the certificate contains only the public key, so "renewing the certificate" does not necessarily imply changing the private and public keys; the CA could just take the existing certificate, change the validity dates, and resign it. But if the private key is changed, then so is the public key; changing the private key thus implies obtaining a new certificate.
Using a new private key may help in achieving a reduced form of Perfect Forward Secrecy. The issue that we want to deal with is the possibility of theft of the server's private key after the key was used. If the attacker records a TLS session, then, at a later point, steals the private key, then he may decrypt the session that he previously recorded.
Renewing the private key will grant you PFS insofar as the previous key is destroyed; it is not the obtaining the new key which grants PFS, but deleting the old one. Presumably, once deleted, the old key can no longer be stolen. This must be taken with a grain of salt, though: during the week the private key was active, it was stored on a physical medium (the hard disk), and really deleting data from physical mediums is tricky. It may also have been copied to some backup tapes or something similar.
SSL/TLS has a better way to obtain PFS. You get PFS by using one of the "DHE" cipher suites. With these cipher suites, the server's private key (the one corresponding to the server's certificate) is used only for signatures; the actual key for encryption (precisely, for key exchange) is a dynamically generated DH key pair, which the server never stores; the server keeps the private key in RAM only, for a few seconds. Since the key is never written to a file, it is much less susceptible to ulterior theft.
The symmetric key has nothing to do with PFS. In SSL/TLS, you always get a new symmetric key from each handshake: client and server send random values to each other, and these values enter in the computation of the symmetric encryption keys. PFS is not about using a new symmetric key; it is about not storing the asymmetric private key which would allow for reconstruction of the symmetric key (the DH private key for a DHE cipher suite, the RSA private key for a RSA cipher suite).
For a primer on how SSL works, read this answer.
