On another side, if you assume that other vulnerabilities don't exist, and you do such things online like banking or trading, and you accept that the sites use JavaScript, I don't see any argument why the crypto primitives which run in addition to the rest of the code, everything delivered over TLS and from the same site, are any more suspicious than the rest of the JavaScript.
The advantage of the encryption on the client side is obvious. Of course, it would be even better to have the client side encryption controlled by the user separately from the site. But under assumption that I personally control the server from which I deliver my html and JavaScript over TLS, I still feel better having the possibility to encrypt something that I'll upload to the server as long as I assume that the browser is not attacked.
The only thing missing is the possibility to somehow checksum the delivered html and code and then "lock" that in my browser. It's not something scalable, I know.
But the problem is never that much technical as it's "political." Consider Dropbox: in many use cases, they would be able to have all the encryption on the client and not to deliver the key to them. However they do deliver the key "because the users will need it." Who says that? They, and I can't choose.
Technically, the solution can be certainly achieved, the problem is that it's not an interest of the current service providers.
Maybe is Mega the first one that really has such interest?