tl;dr: the expiry date is no reasonable mechanism to protect the primary key, and you should have a revocation certificate at hand.
The slightly longer version is, that the effect of the expiration date differs between primary and subkeys, and also what you aim to prevent.
For subkeys, the effect is rather simple: after a given time frame, the subkey will expire. This expiry date can only be changed using the primary key. If an attacker gets hold of your subkey (and only this), it will automatically be inactivated after the expiry date.
The expiry date of a subkey is a great tool to announce you switch your subkeys on a regular base, and that it's time for others to update your key after a given time.
For primary keys, the situation is different. If you have access to the private key, you can change the expiry date as you wish. This means, if an attacker gets access to your private key, he can extend the validity period arbitrarily. Worst case you lose access to the key at the same time, then you cannot even revoke it any more (you do have a printed or otherwise offline and safely stored revocation certificate, do you?). An expiry date might help in the case that you lost control over the key, but no attacker has either. It will automatically expire after a given time, so there is no valid key with your name you cannot use on the key servers forever.
If you've got a revocation certificate and are sure you never might lose access to both your private key and revocation certificate at the same time (consider fire, (physical) theft, official institutions searching your house), there is absolutely no use in setting an expiry date apart from possible confusion and more work extending it.