Two ways to check whether something's been revoked
A certificate revocation list is a published list of certificates explicitly revoked before their normal, stated expiry — a certificate that was compromised or mis-issued, despite its printed expiry date still being in the future. A verifier checking a certificate's validity is supposed to consult this list, not just the certificate's own expiry, since a certificate can look perfectly valid by its own metadata while actually having been revoked.
OCSP offers an alternative: a live, real-time check of one specific certificate's status, rather than downloading and searching an entire list to answer the same question. This trades the cost and staleness of a periodically-downloaded list for a live, per-check network dependency — the responder answering the query has to actually be reachable, introducing exactly the kind of availability dependency a locally cached list avoids.
The same tradeoff, in a higher-stakes form
Neither approach is strictly better in every situation; each accepts a different balance between freshness and reliability, which is the same tradeoff authorization caching runs into everywhere else, applied here specifically to revocation status. A revocation check that's too infrequent can honor something that's already been revoked, well past the point it should have stopped being trusted — and a revocation-checking design has to choose deliberately between the two approaches, or combine both with an explicit fallback, rather than assuming one is simply correct and the other obsolete.