The main point of the article is that if the server sent you the JavaScript, you're already trusting the server, so you might as well do the crypto stuff server side and use SSL for transmission.

Browser-based crypto is by no means our end goal, but rather a stepping stone. Here are some of the things I am working on or predicting:

Downloadable bundles. There is no reason you can't take the HTML/JS from bitcoinjs-gui, package it up as an AIR or xulrunner app and have people download and install it. It would then have the same properties as regular Bitcoin with respect to software delivery.

Software security device. If you have more than a few bitcents you can install a piece of software that moves your keys and the crypto outside of the browser. If you initiate a transaction within Webcoin or another client, the locally installed software will pop up a window showing the details of the transaction pending your final confirmation.

Building a dedicated software security device will also pave the way for:

Hardware security device. For even larger amounts no measure of software security will be sufficient. A hardware device with a display and internal signing would definitely by a major step forward.

Split key signing. Half your key is on your device, the other half is at a wallet hosting service. The service could offer any kind of verification you want: Yubikey, SMS, phone call, whatever. You'd probably set a daily limit. Under the limit you don't need any special verification. Note that you could have both keys as physical backups, so you wouldn't be dependent on the hosting service if they decide to randomly disappear one day.

Also I want to point out that the only part of BitcoinJS that this criticism affects at all is Webcoin. I know some folks are working on various native clients that use our server APIs, but could be implemented in Java, Objective-C, C#, etc.