I mostly agree with the gist, but it's not really the Javascript that's the problem. It's trying to do crypto in code downloaded over the network. Implementing crypto in a Flash/Java/Flex/Silverlight/other flavor-of-the-month applet has all the exact same problems. Well, you might have a secure RNG (doubtful), but apart from that the problems are all the same.
Likewise, it's probably possible (though very difficult, and still not a good idea) to have good crypto in JavaScript as long as it's either server-side or built into the client.
Java crypto doesn't have all the same problems; the Java plugin environment has enough code to run crypto inside of it, and Java applets are (or can easily be) self-contained enough to verify integrity. Browser Javascript (and by extension Flash) is a uniquely hard place to make crypto work.
If by "has enough code to run crypto inside of it", you mean "the SSL support and the javax.crypto library", sure, it gives you some useful stuff. You can also access all that stuff from JS without ever writing a line of Java code, so that's a wash.
As far as self-contained Java applets go, every attack that can be used against JS can be used against Java. It's a trivial exercise to instrument any method call you like, including calls to any method that attempts any kind of verification. Java bytecode is really quite transparent.
Likewise, it's probably possible (though very difficult, and still not a good idea) to have good crypto in JavaScript as long as it's either server-side or built into the client.