I don’t want to dive too deep into Telegram since that’s a whole other discussion, but just for this point, I think you may have misunderstood the page you linked to. It looks like what you’re referring to is “Telegram stores regular cloud chats encrypted on their servers but they control all the encryption keys.” This sentence is about the “regular cloud chats”, not the chats where you turned on E2EE encryption. But maybe you mean something else (in that case, please actually point out what you mean), or maybe the mtproto encryption keys are actually sent to the server somewhere (I’d like to think that would be super major news and I would have heard of it).
Fun fact: I applied to be on their volunteer support team when it was brand new, but was rejected because I didn’t want to lie about the security of non-mtproto chats. (To an example support query, I replied that standard chats are readable by Telegram. That is apparently false, according to Telegram themselves. “No, we’re partially blind, we can read our own keystores or our encrypted message stores but not both at the same time except when returning data to one of your clients!” would have been a correct answer :D). I feel like we agree about Telegram to a large extent.
Again, you link a resource without pointing out what part of it you refer to. I know Keybase chat uses all sorts of crypto as the page describes, but I can’t verify any of it as a user. To do E2EE, the server has to send me keys from my contacts (like a public key or diffie-hellman numbers). What the server sends me isn’t shown anywhere. I have to either compile it myself with added debug output, or maybe I can view internal state with root access, but there is no built-in mechanism to display keys to verify that (assuming all chat participants have trustworthy APKs) Alice and Bob use the right encryption keys and are not being MitM’d. Unless I’m overlooking some very obscure menu, this is not end to end encryption because my client believes whatever the server says and I can’t verify it.
Since claiming that “even Telegram or WhatsApp do better in this particular regard” is apparently perceived as foolish and make you stop reading, let’s take Signal: there I can view the “safety number” to see that I have Alice’s or Bob’s real key. A malicious server (the thing E2EE protects against) is detectable by out of band comparison of this number.
Well, since I replied in the way that I did, apparently that wasn’t that clear to me.
I guess this is what I mean by the decision to delist Wire being gut feelings: a number of reasons are mentioned, and for each of them it’s literally impossible to tell how the risk changed. Neither of us can tell. What you perceive as biggest risk, may feel different to me.
Silently changing jurisdiction, silently accepting money from a US investor, having the US government as a customer: neither of us knows whether this investor bribed them to build in backdoors, it just doesn’t seem very likely to me. (Note the word “seem”: I don’t know, but neither do you.)
The biggest deal for me is moving to the USA. It’s yet another service controlled by a US entity, and it seems like we (as western European countries) cannot get away from being wholly dependent on a specific other country. Wire is something one does not have to self-host and still get strong encryption, so it could have replaced something USA-based like Signal. Now, that benefit of not sending your metadata to the USA (or at least, the USA being able to obtain it through legal means) has been removed. Since the silent jurisdiction move is apparently the reason that triggered the delisting, I assumed we both found that the most concerning. Apparently it was not the main concern for you, but that wasn’t clear to me, and that doesn’t change that most of these reasons are mostly subjective (the most objective impact, as far as I see, being that the USA can now legally require Wire Swiss GmbH, as well as all other chat services popular in Europe, to disclose their metadata).