I know client side encryption is generally not seen as ideal.
I don't think that's true; you may be mixing up a few different things.
One of the canonical rules in secure software design is to never trust the user. This means that any time you do, say, validation that a form field is in the correct format, you must do that on the server, or else an attacker can feed your application an attack payload. This holds true to certain forms of cryptography as well, as long as it's something where your application will interact with the resultant data.
What you're talking about here is end-to-end encryption. In these situations, the encrypted data is only ever dealt with in the server-side application as a binary blob. This is only useful in a few situations, like cloud storage and messaging apps, and you give up the ability to provide features many users want, like sophisticated search.
So to answer your question,
Thus, if you were trying to build a company where even if the government forced you at gun point to give up the data of a certain user, wouldn't client side encryption provide you, the server owner, with better protection from such an ultimatum?
Yes, end-to-end encryption does.
There are further things to consider, though. Is the client application closed source? Then how can the user verify that you aren't sending the data off unencrypted to your (or the government's) servers? Is the client application installed through an app store? How can the user verify that you haven't pushed a new version of the app that makes significant changes from the one they audited? Is the client application installed as a binary? How can the user verify that the binary you're providing comes from the unmodified source that they've read? The recent Apple FBI controversy dealt with some of these issues.
Also related is the subject of forward secrecy, in which a key that's been handed over to the government doesn't allow them to decrypt past conversations.