If you naively depend on the client, sure, it will be game over, but that is true of any naive security.
Endpoint encryption does solve many problems, but it doesn't solve all of them. Take a bank case: sure, you could encrypt your account number and transfer amount on your machine, but the how is the bank supposed to do anything with these random bytes you've sent? If they have the keys (like they do with SSL), we aren't any better off.
With some complex public key crypto, you could maybe make things better, but you would be dependent on everybody treating their private keys well. I'm not convinced big companies could manage that, much less "Joe the Plumber".
Trusting the client is not the same as securing the client.
Edit: I didn't like my initial tone, so I backed off.
Encryption prevents leaked data from being meaningful. No amount of server-side security, including query parameterization, can guarantee the absence of leaks. Client-side encryption makes leaks much less devastating.
How encrypting user data in JS on the client is different from properly hashing user passwords in JS on the client? It is now accepted that sending and storing passwords in plaintext is bad practice; the logical next step is to encrypt not only passwords, but all data on the client.
Encrypting a password on the client-side means that all a cracker needs to login is the hashed password, which is exactly what they would get from a database dump, thereby bypassing the entire point of hashing the password in the first place. (Yes, I'm aware you could use a different salt on the server than the client, but that would require that the client-side encryption be reversible, which is perhaps even more problematic.)
Client-side encryption, even in JS, would have prevented this, it seems.