Please read the article again carefully. I think you'll find the answers to your questions.
Yes, it is important to be aware that security is always relative to a threat model, and at times it can lead to confusion when threat models are not made explicit. That does not mean, though, that it's necessarily wrong to imply a sensible threat model in a given context, and to just call something "insecure" without any further explicit qualifications if it does not protect against a reasonable minimal threat model that essentially everyone essentially always has to face.
Also, it's questionable whether you can call the NSA's mass surveillance a passive attack, given that QUANTUM INSERT exists and was used, in order to attack foreign communications infrastructure.
Is it like saying that a tank made of paper sheets is insecure, or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?
It is never okay to omit important information like the threat model in cryptography. That information is essential to the system's analysis.
Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face.
> or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?
No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is intended for. Whereas, JS crypto is presumably intended to protect users when the remote server can't be trusted. (What else would it be for?) It can't offer such protection.
That's the part to which I'm objecting. As I asked above, what is the proper use of JS crypto? What real-world application do you have in mind where JS crypto's level of security is adequate?
In general, anywhere you aren't basically doing what amounts to an eval() on an external resource (so packaging everything locally, aggressively filtering XSS attacks) can be a good use of JS crypto.
I don't think JS crypto itself is the issue. I think the issue is more pulling your code from an external, ultimately untrusted source. You can do this in many languages, and it's equally a Terrible Idea in all of them. Granted, some things auto-update and can verify an update via a packaged public key, but the model of continuously downloading code on each run, while easier on app developers, is a ticking time bomb for crypto.
Those are probably acceptable in principle. I should have been more specific: I was referring only to the scenario wherein the webserver provides the JS.