OCSP enabled or not, you're still one website click away from being pwned to oblivion, giving full control to the hacker – which, of course, is inevitable to an extent, since bugs always find their way into software.
So why not make it easy to disable?
> Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you.
Sure, but we're discussing good-faith security here. Presumably if people complain about a missing feature they can envision using it. The scenario here is not visiting a shady website and doing something stupid, the scenario here is something like a man-in-the middle attack using a revoked certificate, which would by definition by difficult for the end-user to detect.
> So why not make it easy to disable?
Because then people would disable it for no discernable good effect.
I mean let me be clear, if you're a security researcher you can just modify your own HTTP stack, run a VM, control the hardware, whatever. This isn't a blocker to investigating HTTPS reactions sans OCSP—this is about denying secure connections when they've publicly revoked the cert used to sign the connection. The only reason this is even considered a discrete feature is that most people have never written an OCSP request in order to then trust an HTTPS server—you're just opening yourself up to be misled without even realizing this (and this goes for most of my very network-stack-aware coworkers).
If you're in a browser, you want the browser to be using best practice security, which necessarily includes OCSP. If you know what you're doing this is trivial to bypass.