Firstly, for a certificate to be useful, one half of its asymmetric key pair has to be made public, and the other half must never be shared. Therefore a certificate can only protect traffic in one direction: encrypting traffic with the private half would be pointless (anyone could read it), and traffic encrypted with the public key would only be readable by the end holding the private key.

Secondly, certificates are not used to encrypt traffic; rather, they're used to sign symmetric encryption keys that are randomly generated anew for each connection. This is especially useful where two communicating endpoints are not under common administrative control. This is done because it's vastly more efficient, and avoids needing separate key pairs for the traffic in each direction.

Thirdly, a certificate or encryption key should generally have a limited lifetime because:

1. over time there is an ever-increasing (cumulative) risk that the devices holding a private (or symmetric) key may be compromised (and you can't use a compromised key to distribute its own replacement);
2. they may be weakened (or completely defeated) by advances in cryptanalysis; and
3. they will eventually be threatened by Moore's Law.

A certificate's lifetime is set such that there's an extremely small chance of any of these happening before it expires. Ephemeral symmetric encryption keys generally have extremely short lifetimes, usually no more than a few hours.

Firstly, it's misleading to describe a certificate as “its purpose is to encrypt traffic”. Its purpose is to protect traffic, but not by being the key used to encrypt it.

A certificate comprises (among other things) an asymmetric key pair. Using this key pair to encrypt & decrypt network traffic would be awkward for a variety of technical reasons, but if you managed to jury-rig things to use one of the keys in a certificate to encrypt traffic, you would run up against a more fundamental problem: to be useful as a certificate, one half of its key pair has to be made public, and the other half must never be.

As a result, your jury-rigged encryption would only be useful in one direction:

• traffic encrypted with a public key would only be readable by the end holding the corresponding private key; and conversely
• encrypting traffic with a private key would be pointless (anyone holding the corresponding public key could read it).

You could of course work around this shortcoming by having a separate key pair for each direction, but nobody does that in practice, mostly because asymmetric encryption algorithms are far more costly than symmetric ones.

Rather, traffic is exchanged over a session protected by a symmetric cipher, whose key is ephemeral - it exists only for the duration of that session.

The certificate comes into play when proving the identify of (one of) the endpoints; in doing so it offers a secondary proof against a MITM attack.

As for why certificates expire: any certificate should have a limited lifetime because:

1. over time there is an ever-increasing (cumulative) risk that the devices holding a private key may be compromised (and you can't use a compromised key to distribute its own replacement);
2. they may be weakened (or completely defeated) by advances in cryptanalysis;
3. an attacker might just get lucky and guess the key; and
4. they will eventually be threatened by Moore's Law.

A certificate's lifetime is set such that there's an extremely small chance of any of these happening before it expires.

The same arguments for key apoptosis apply equally to symmetric encryption key and private keys, but ephemeral symmetric encryption keys generally have lifetimes that are many orders of magnitude shorter than certificates, so a more significant worry is that encrypted streams might be recorded by an eavesdropped and then decrypted using new cryptanalysis techniques possibly many years later.