The author doesn't say that they are, he's simply listing reasons that a user may have JS disabled, and hence why it's a good idea to employ progressive enhancement, so that such users are not entirely locked out of using your app.
If you want to tackle these specific reasons, just serve the site via SSL. Other reasons for progressive enhancements might still persist, but the listed cause bigger troubles than "JavaScript does not work correctly" and SSL is a complete solution to all of them.
You're conflating user and service designer here. The user has a problem (including but not limited to those listed) and so turns off JS. The service then has the problem that JS is disabled... no amount of SSL will help if your pages require JS to load.
Edit to clarify: The user turning off JS and using the service are likely to happen at entirely different times. If you browse with JS turned off, it's likely off by default and only enabled when needed (if at all).
How many users actually disable JS for these (or any other) reasons? Might it be cheaper to e.g. have a call center that trained to use the website on behalf of such users, rather than increasing the development costs of every government site?
Last time we checked we get ~180k visits a month from people who specifically disable JS, ~810k further visits a month from people who don’t have JS available.
So no, it’d be more expensive to have a call centre.
I don't like this idea because it sacrifices ease of use in order to make small savings during the development phase. You shouldn't subject your users to extra grate where possible, and I think this is especially true for a government site.
