The big use case for this would be for workplace use, not for social / community use. In that case, since it's the company's account system (whether it's actual SSO, or just access to the email account where password resets go) that authoritatively identifies users, it's reasonable for the company's IT department to have a way to issue replacement keys that can also decrypt the data.

Encrypting data client-side doesn't make it difficult to share information between other users of the same system: all you do at the protocol level is send them a message with the data, or perhaps with a key for decrypting a stored file. It's really just a matter of UI to make it smooth. If anything, it makes it slightly easier because you can use any transport mechanism you like for sending the ciphertext; you're no longer obligated to route everything through HTTPS connections to a single server. So, for instance, you can throw encrypted uploaded files in an S3 bucket, and maintain availability for existing data even if the service provider is having an outage, because users can access and decrypt that data using their client.

It does make it more difficult to share it outside the system (to people without accounts) without storing it decrypted.