1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and thus by default better from a security standpoint.
2. The client side code is obfuscated. The server-side code is not provided. To perform a reasonable analysis of a system's security, a reviewer needs unobfuscated access to both. Why would you try and make security and crypto researchers de-obfuscate or guess your code, when that is not their specialization?
1. As discussed in another comment, this requires a similar level of trust to encrypting the data on the server. The only difference here is that, to the best of my knowledge, an attacker who took control of the server, could silently log the plaintexts in the server side case while some indication would be provided in the client-side case. Most wouldn't notice it but some would eventually.
1. A server could silently insert code that replaces your keys with a well known one. Don't kid yourself into thinking anyone would notice this if it was silently tucked away in the minified angular or SJCL code.
2. Your definition of obfuscated and mine clearly differ. I'll be more direct: where's the (well-commented, clearly coded) model/controller code?
2. The client side code is obfuscated. The server-side code is not provided. To perform a reasonable analysis of a system's security, a reviewer needs unobfuscated access to both. Why would you try and make security and crypto researchers de-obfuscate or guess your code, when that is not their specialization?