How is this any different from a XSS bug resulting in an attacker stealing the plaintext password from a form?
Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?
If the client and the server can trust each other, then JavaScript encryption literally adds no benefit.
Think of it this way: your browser contains some areas whose sole responsibility is to verify the authenticity of a remote server (SSL), and those areas are completely inaccessible from the DOM. So, basically, as long as you can trust your web browser, then you can trust the connection.
But those protections don't exist for JavaScript. An attacker could compromise your server, rewrite your JS, and you'd never notice. (No JS signing capabilities in the browser; no TOFU/POP style architecture.) An attacker could use an SQL injection on your CMS to leave a comment that uses XSS to modify your JS encryption while it's running, and you'd never notice. You could be on an unsecured network and someone could MITM rewrite your JavaScript in-flight, or, in the cases of bad JS crypto implementations (which almost every single one is), simply use a replay attack at their leisure.
There are all kinds of really neat ways to attack JavaScript.
It's true that there are also almost as many ways to attack any other authentication/encryption system, but the point with attacks against JavaScript is that JavaScript adds no extra security at all -- it is at least as vulnerable to any of these as anything else is -- and it adds a false sense of security, and it is vulnerable to things that SSL is not, and in some of the scenarios, you will get absolutely no indication that you've been compromised.
Also, given that the client and the server trust each other and communicate securely, doesn't this just get reduced to the probability of having these bugs and nothing more?