Be careful taking this advice. "Get rid of all the options" can actually be quite powerful... it makes software that "just works". But it also makes software that "just doesn't work". The reason that these suggestions make sense is that Firefox allows plugins and extensions which CAN allow for these things.
Perhaps the moral of the story is to build your software with layers of configurability. In layer one, there are hardly any choices, but there is an "advanced" button to allow further configuration. In layer 2, there are many more options, but still only "frequently-used" features... however, there is a plug-in or scripting system that allows adding additional features if a developer makes them. The ecosystem of plug-ins would be layer 3 (note that this only works if you provide a common place to DISTRIBUTE the plug-ins and you make an effort to filter out malware). Finally, layer 4 would be the ability to build one's own plug-ins, but this layer would only be available to developers.
I have some software (like browsers, IDEs, and even older things like Emacs) that works like this today... but maybe all software should be built with layers of configurability.
Over the years I've gradually concluded that extension mechanisms are actively harmful. Firefox leaves features that should be integrated (tab management, developer tools) down to extensions; in Opera these features were always more usable and better integrated. Emacs defers to extensions for things that Vim does natively - and again, the result is those features are more usable and better integrated. Eclipse makes everything a plugin, and often this leaks up to the user; it frequently happens two features will either not integrate nicely with each other or even be impossible to install at the same time; contrast with IntelliJ IDEA where all the features are built in, with the result that it "just works".
While disabling Javascript is something sure to break a lot of websites, it is something that I use regularly to test the websites that I am building so that I can confidently assert that disabling Javascript won't break MY website.
Same thing with disabling images. I have built web applications for the browser constrained (think remote science stations in Antarctica), and we often wish to test rendering without images (or with massively deferred image loading) or with only partial page renders to ensure that the first content loaded is the first content displayed for those situations where they are needed.
Sure, I'm a fringe case, but for some people, "breaking the internet" is a job requirement.
I'm not a UI guy, so my point wasn't whether or not the checkboxes should or shouldn't exist, but to clarify that all the use cases he asserted "broke the entire internet" had valid uses and represented the desired behavior.
That it happens to break a few popular websites doesn't mean that the entire internet is broken, or that that wasn't the desired effect.
Be careful taking this advice. "Get rid of all the options" can actually be quite powerful... it makes software that "just works". But it also makes software that "just doesn't work".
To be fair, the post didn't advocate getting rid of "all the options". It advocated getting rid of options that almost never make sense to use. For many of the examples given, that would continue to apply even for power users.
Indeed, I am in full agreement with the original post -- which proposed this policy for Firefox, a tool that HAS multiple layers of configuration. My only point was for others not to blindly apply "remove options", but to consider what Firefox REALLY has, which is different layers of configurability.
Perhaps the moral of the story is to build your software with layers of configurability. In layer one, there are hardly any choices, but there is an "advanced" button to allow further configuration. In layer 2, there are many more options, but still only "frequently-used" features... however, there is a plug-in or scripting system that allows adding additional features if a developer makes them. The ecosystem of plug-ins would be layer 3 (note that this only works if you provide a common place to DISTRIBUTE the plug-ins and you make an effort to filter out malware). Finally, layer 4 would be the ability to build one's own plug-ins, but this layer would only be available to developers.
I have some software (like browsers, IDEs, and even older things like Emacs) that works like this today... but maybe all software should be built with layers of configurability.