There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities.
Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.
Well that depends entirely on wether you've configured your environment securely. If your sql server runs as an unprivileged user preferably on a different machine this should not be an issue.
Even if someone were impressively thoughtful about that, they'd still cough up arbitrary code execution on the web tier for most Rails / Django applications, by writing an appropriately serialized external command into the queuing system. That external command would be loading metasploit into /tmp and then gaining root with a local privilege escalation.
Thomas is right, though: if you lose the DB, you're forked.
So you obviously don't agree, care to elaborate? You seem to be the expert here..
(btw I don't mean that command execution is not a problem, I mean that if you configure your sql server well it should not allow command execution, there's not _that_ many ways to escape the database..)
This is one of those discussion where when I point out mistakes that (a) everyone makes and (b) you haven't thought of before and (c) are exploitable whether or not you encrypt, you're going to say "oh, well, you just shouldn't make those mistakes", and so I'm not interested in pursuing this and am content to rest my case.
Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.