How is issuing a certificate revocation response different from re-issuing the certificate itself?

How is issuing a certificate revocation response different from re-issuing the certificate itself?

I am reading about how certificates work in the context of X.509, SSL/TLS/HTTPS. According to Wikipedia, the client (e.g. a browser) is supposed to check the revocation status for each non-root certificate as a part of certification path validation. The preferred way (see comment) of doing this is an OCSP request or OCSP stapling. Wikipedia also says that an OCSP response is signed by the CA that issued the certificate in question (item 6 below):

1. Alice and Bob have public key certificates issued by Carol, the certificate authority (CA).
2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.
3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Carol.
4. Carol's OCSP responder reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Carol maintains. In this scenario, Carol's CA database is the only trusted location where a compromise to Alice's certificate would be recorded.
5. Carol's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
6. Bob cryptographically verifies Carol's signed response. Bob has stored Carol's public key sometime before this transaction. Bob uses Carol's public key to verify Carol's response.
7. Bob completes the transaction with Alice.

It is also said that the CA can certify a third party to provide revocation checks for certificates that the CA issued:

The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question

I have the following questions.

1. If the CA does not delegate OCSP responses related to certificates it issued, how is creating OCSP responses different from creating short-lived certificates and re-issuing them?

OCSP responses have to be produced for each certificate every x minutes or days, and so would be the certificates. If the subject's key pair or identity is compromised, then revoking the issued certificate via OCSP is equivalent to not extending a short-lived one. If the CA's key pair is compromised, a malicious actor could fake a favourable OCSP response with these keys. Also, if the client chooses to soft-fail when a revocation check is unavailable, they can equally accept a short-lived certificate that expired just recently. From the subject's perspective, OCSP stapling seems equivalent to attaching short-lived certificates. I can't see any substantial difference at all.

2. If the CA involves an intermediate party (or an intermediate certificate of its own) in handling OCSP responses, what are advantages of this? Again, how would it be different from the same intermediate entity or certificate issuing short-lived certificates for subjects?

It could be that I completely misunderstand the point of revocation checks, in which case I'd appreciate an explanation.