I'm not going to comment on the linked article, other than say I think it contains serious mistakes in describing what OCSP is for and errors in other statements. In the background there is a war going on, but it isn't what you think. It is a war between malware creators and OS creators. From my perspective it goes like this: To "identify" malware you need signatures. Signatures need valid certificates. Signing keys…
This all sounds well and good. But why not just use signed binaries? Have a user editable keystore that includes the accepted signatures. The default would be apple, installing chrome would require accepting the Google signature, photoshop would require the adobe key. Then users could add their own for brew, firefox, or whatever community software they would use. This would give good protection against hackers, and n…
Operating a "trusted" Certificate Authority generally requires operating under some rules. For example, the "Certification Authority Browser Forum" requires operating a CRLs (now considered bad) or a live OCSP endpoint.
Let's Encrypt does this, as does every other certificate issuer.
As is being discussed, separate OCSP is bad from a privacy standpoint - if a check of OCSP is being made, it gives telemetry on if you are trying to validate a certificate. If you can see the traffic it does reveal the certificate being checked.
FWIW, there is an OCSP Stapling method of attaching "recent" OCSP responses inside of TLS requests so that a TLS client doesn't have to make a separate request to an OCSP service.