with closed source, hosted software E2EE is as much about trust as it is about technology since you can't verify its implementation. arguably, if trust is there, E2EE doesn't get you much anyway other than for scenarios where the company itself is breached. in any case, if the trust isn't there, you can't validate the E2EE, so your risk profile with regards to using the software doesn't change much.
You can verify closed source E2EE as long as you can inspect the traffic going client-server. The problem is that most E2EE apps allow auto-updating, so baking in something that transmits info to a third party is easy (but detectable with enough eyes on the code).
As for the threat model of open source E2EE apps auto-updating to an insecure version, you're right that this needs some extra defences. One way would be to use a binary-transparency log[0] to make sure that the open source project had publicly committed to a specific binary at least 24 hours in advance of pushing the auto-update.
This system relies on there being auditors out there who would raise the alarm if a malicious update was released, or a hash was included in the log for which there was no corresponding (reproducibly buildable) source code.