1. Revocation is broken. The obvious way for revocation to work (your browser checks if the certificates it sees have been revoked) not only has negative privacy implications (so e.g. Firefox does not implement this) it also plain doesn't work. It has "fail-open" behaviour for a bunch of sad but inevitable social reasons. In theory we have viable fixes for this, but in practice we can fix really big problems (e.g. a whole CA is compromised) with a lot of effort and smaller problems (e.g. your IT guy emailed your private keys to a scammer) mostly not at all. Thus, expiry is the hard stop, if your certificate expires in six weeks, the scammer loses any benefit [edited] in six weeks. Problem "solved" or at least mitigated.
2. The Web PKI can only evolve at the rate permitted by certificate expiry. Anything faster will set important stuff on fire, because no matter how hard you try you can't publicise changes enough to ensure people are aware of them. e.g. Everybody needed to stop using SHA-1 certificates, that took several years, when the same happened for MD5 it took so long to be effective that even though it was deprecated before a reliable collision was known there were multiple successful attacks anyway. Under Apple's current 12 month rule, if we need to fix something ASAP, we can either break the world, or we wait until late 2022. But under the historic Five year rule that becomes break the world or don't fix it until 2027. That's a pretty big difference in how agile we can be without telling everybody, "Sorry, we broke the whole Internet, reinstall and try again".
Now, I assume that the list of people who visit Porn Hub isn't valuable enough to justify the CA (DigiCert again) explicitly monitoring who visits the site and selling it when they already charge PornHub good money for a certificate. But who knows?
SNI is even more accurate, because things like cloudflare certs are often for 100s of different domains with many wildcards.
eSNI has not really taken off yet, so almost always your requests are saying the exact domain you are going to in clear text.
However, the bit about the CAs getting some analytics about certs they issue is valid.
Setting required to true just makes it actually demand a response instead of allowing an MITM to block it making OCSP ineffective.
At the end of the day we need to start progressively rejecting certificates that aren't OCSP stapled to fix both sides of this, but for now this is the best fix available for technical people who understand how OCSP works.
Yes.
But for the larger global problem, OCSP stapling is a solution in the same sense that "Don't dig up any more coal, oil or gas" is a solution. Yes, I urge you to do this in both cases. It's a good idea. But, is everybody going to do it tomorrow? Next year? In my lifetime?
If the certificate is only valid for three months however, many people will automate the renewal right away, because nobody wants to do this manually every couple weeks.
From a security POV, shorter lifetimes require more periodic checks for the server's identity. E. g. a Letsencrypt-issued certificate using the ACME protocol will validate the server really belongs to the given domain more often, which is a nice property I think.
Let's Encrypt explains their choice for 90day certificates here: https://letsencrypt.org/2015/11/09/why-90-days.html
edit: With 3 year certificates there is also a greater risk for certificates expiring unexpectedly because the renewal process happens so infrequently. The person with the knowledge on the renewal process might not be at the company anymore by the time the certificate expires.