The theory of X.509 is that revocation checks should occur on all certificates -- not only all certificates in the chain, but also for any extra certificate which was needed to validate the revocation information (CRL, OCSP response...), recursively.
Of course, theory and practice match perfectly only in theory. Some systems (browsers, OS...) will do not check at all. Some will check only the leaf. Some will check revocation status for all certificates in the chain (but not for extra certificates, if these happen to be used). Moreover, the systems differ in their behaviour when revocation status cannot be obtained (e.g. CRL download fails, or no CRL/OCSP URL can be located). Moreover, such behaviour also depends on whether the certificate is supposed to be "EV" or not: EV certificates are called such because they result from agreements between CA and browser vendors; browsers display them with a specific graphic code (which supposedly increases user's confidence and trust) on the basis that they also enforce stricter checks, including a whole-chain revocation status check.
See this page for a discussion of issues and solutions about revocation status checks in the Mozilla family of browsers (i.e. Firefox).
Also, remember that revocation status check is, ultimately, a damage containment feature: when a private key is stolen, and the theft is discovered, then the CA can enforce through revocation an "early expiration", which shortens the time window during which the key thief can leverage his indelicacy. In practice, you would be hard pressed to find an actual case where revocation saved the day. As Peter Gutmann says, stricter revocation checks don't actually prevent anything that attackers really do on non-EV certificates (as observed in the wild).
Even when private keys are actually stolen (this does not happen often), the asynchronism which is inherent to revocation handling means that attackers get at least a few hours of free access. The core point is that revocation is reactive: regardless on how often you issue CRL or update OCSP servers, revocation may occur only after the key theft has been discovered and reported to the CA. In practice, when a private key is stolen and used by attackers, the theft is detected because the attackers have setup a fake site which uses the stolen key.
