Re: To be clear ...
I'm not sure why you think I'm disagreeing with you or defending their claim. They should not be claiming end to end encryption. Anyone clever enough to implement encryption correctly knows damn well what that term means and TLS between server and client is not sufficient.
Point 1 is absolutely correct. It should not share the key with the server if you are not asking for a cloud based MP4 to be available. It does though, hence the controversy.
Point 2 would work, but that isn't what the feature does. You are trading off convenience of a sharable MP4 link for the complexity of requiring a bespoke player and a way to securely distribute the keys to your recipient. Again power to you if that's how you want to share it.
I agree 3 would be a reasonable compromise.
On your dial in suggestions, point 1, faking your dial in number is orders of magnitude easier than compromising the key.
Point 2 would work of course, but now your company needs an extra 50 phone lines for that once a week call. Similar to point 1, there are some security compromises in proving that the incoming call is the authorised party. It also means that all audio of that call is going through a public phone system, so that's where the weakest chain link is.
I don't disagree with point 3. If I ask for an end to end encrypted call, I expect any feature that cannot operate under that constraint to disable. It is wrong to create a false impression of security.