Not a stupid question. In fact Google proposed requiring either OCSP or a short-lived certificate on exactly the basis you're describing, that they have the same consequences, and Google's infrastructure is already set up to allow the short-lived certificates without problems. That proposal didn't go anywhere, but there's nothing wrong with it in theory.
In terms of the real world, a lot more Certificate Authorities are set up to bulk issue OCSP responses. In theory OCSP responses could be "live" but in practice what happens is periodically (e.g. once per day) you decide which certs are revoked and then you bulk make OCSP GOOD answers and sign them for all the other certs, and upload those bulk answers to a CDN. So now your signing stuff is isolated from the uncontrollable horde of requests.
Whereas in contrast a lot of CAs (not the biggest one in volume terms, which is Let's Encrypt, but most of the others) have humans involved operationally in issuance, which means higher issuance volumes drive up costs, and they'd have to recoup those costs by charging more. So for you as a customer of those CAs OCSP looks more attractive.
In the non-stapling modality OCSP also doesn't mean any changes to your five year old unsupported custom server software, whereas replacing the certificates every week might mean somebody has to manually paste text from a file into a crappy web form and press "Replace certificate" every single week. Ugh. Such a server of course will turn out not to be capable of OCSP stapling, so if we want that we could have just upgraded it to have a sane certificate automation protocol rather than teach it how to do OCSP stapling...
In terms of the real world, a lot more Certificate Authorities are set up to bulk issue OCSP responses. In theory OCSP responses could be "live" but in practice what happens is periodically (e.g. once per day) you decide which certs are revoked and then you bulk make OCSP GOOD answers and sign them for all the other certs, and upload those bulk answers to a CDN. So now your signing stuff is isolated from the uncontrollable horde of requests.
Whereas in contrast a lot of CAs (not the biggest one in volume terms, which is Let's Encrypt, but most of the others) have humans involved operationally in issuance, which means higher issuance volumes drive up costs, and they'd have to recoup those costs by charging more. So for you as a customer of those CAs OCSP looks more attractive.
In the non-stapling modality OCSP also doesn't mean any changes to your five year old unsupported custom server software, whereas replacing the certificates every week might mean somebody has to manually paste text from a file into a crappy web form and press "Replace certificate" every single week. Ugh. Such a server of course will turn out not to be capable of OCSP stapling, so if we want that we could have just upgraded it to have a sane certificate automation protocol rather than teach it how to do OCSP stapling...