I hate this, and love it, at the same time.
The reason these companies are sitting ducks for this type of abuse, is that they run services but also insist that their users use a particular proprietary client. If you were to RE their services and make a compatible client, they would freak out and sue you, because your client doesn't show their ads to the user (and wouldn't reliably count those impressions if it did). So fuck 'em.
But if you don't unnaturally tie the service and the endpoint software together, then you can have a resilient system which is able resist government interference (or at least the boundaries of legal US government interference, until we get around to repealing the 1st Amendment).
Let service providers pass around the ciphertext you give them. This is how PGP and email worked. Yes, it has problems. Laypeople couldn't figure out PGP (and it seems the market has decided that laypeople simply can't figure out key exchange in general), and having the envelope in plaintext means you have to avoid the dreaded "Subject: Your cocaine has shipped" header. But the basic idea is great, in that the service providers really are innocent and have no practical way to stop criminal uses, so it's hard to pretend they're responsible. Holding a generic email provider responsible for what is said in an encrypted email is as silly as holding a road construction crew responsible for a bank heist getaway.
But tie the two together, and the client author can put in whatever weaknesses the government wants, knowing they have a captive audience who has no choice but to either use a deliberately-insecure client, or don't use the service at all.
So in the name of increased privacy for everyone, I'm fine with a "death blow to end-to-end encryption services", because the very idea of an end-to-end encryption service is ridiculous. Run encryption outside of the service. The service doesn't need to know anything about how the user generated the message body.