Let's Encrypt sets date for ending OCSP support

But that's overly reductive. It's probably better to look at this argument holistically. The traditional CA approach looked roughly like this:

* You pay a CA some money for a certificate (and a useless HTML badge that does nothing other than "look professional").
* They issue a certificate, valid for 3-ish years.
* In 3-ish years, your site has a brief outage because the webmaster forgot to set a calendar reminder (or was on vacation, or quit, or whatever).
* You trust the CA, because their entire business model is dependent on them not screwing it up.
* Revocation is largely an afterthought.

The modern approach looks like this:

* You don't pay anyone any money at all.
* Let's Encrypt (or, hypothetically, someone else) issues a certificate, valid for 90 days.
* 90 days is short enough that you basically have to automate it, because it's too painful otherwise.
* You trust the CA, because all of their certificates are in the CT log (on pain of not working in modern browsers). If they issue a bad certificate, somebody will notice and scream bloody murder about it.
* Revocation is still problematic, but less of a dire problem because all certificates expire rapidly, and all certificates are publicly logged, so it is not unreasonably difficult to go and find all of the certificates that might need to be revoked.

In the traditional model, OCSP looks like a somewhat plausible means of making CRLs more scalable. But in the modern approach, this is unnecessary because your CRLs only have to cover 90 days of lookback in the first place. OCSP also has multiple problems:

* Most browsers fail-open if the OCSP service is unreachable, so an active MitM can simply block it.
* OCSP has privacy implications, since it sends all domain names that you visit to the CA for that domain.
* OCSP Must-Staple solves both of the above problems, but is more complicated to set up correctly, and an extended outage of the OCSP service can (eventually) cause an outage of your website. It's not quite as risky as HPKP, but I wouldn't want it on a service I have to sysadmin if I could avoid it.

The browser vendors consume the various CRLs and produce their preferred data, since they own it they get to make the rules, which is beneficial to them and, arguably their users. Suppose a CA says we don't consider that what we did was mis-issuance for 8000 certs, so, we're just not marking them revoked. The vendor can say too bad, we're marking them revoked immediately anyway. Which is a smaller stick than "Since you were uncooperative we're distrusting you"

As with the Web PKI itself, there's a trade off to be made about what you hope to get out versus available resources to do the work. Consuming OneCRL means now you're stuck with Mozilla's choices on everything, but you need only barely enough volunteer effort to write and maintain the OneCRL consumption code, nothing more. A hypothetical GNOME-CRL built the same way would be able to do whatever GNOME wants, regardless of Mozilla, but incurs a considerable maintenance overhead forever.

The biggest thing I expect that a OneCRL is handling is bugs. My guess is that over a year probably half a dozen cases arise where oops, this CA turned off the machine that makes a CRL and so now it's just a 404 or a timeout, or doh, that other CA accidentally uploaded their CRL to the wrong URL every single day for the last six weeks, somebody fat-fingered the destination filename, fetch some-ca.example/CRM.dat instead of CRL.dat. Building a pipeline that's robust against the first sort of nonsense yet flexible enough to cope when the second sort happens will make these worth their time.

As to OCSP stapling, my understanding is that the HTTPS server software is just garbage - especially Apache - and this software has mostly rusted in place, so if you're in the browser client business you can't expect anything which requires the server software to be properly engineered to ever work, you have to base your assumptions on it's garbage, it will never be fixed and nobody who could do anything about that is interested in doing so. It's very much a case of if you don't Do It Yourself (as things like OneCRL do) then it won't get done. This is not a problem for the top 1% sites, your Facebooks, Youtubes, Wordle - somebody is getting paid to keep those working, and they probably read documentation and apply patches _they_ could have OCSP stapling (but many do not). But 99% of sites aren't like that, maybe they were thrown together by somebody's nephew six years ago and live "in the cloud" on a web server which is never maintained and will be gradually rusting until they're taken over by crooks or turned off. They're never getting OCSP-stapling.