Considering only the secure channel problem and not the entire systems problem (which might motivate encrypting clientside in anticipation of the file being stored), encrypting before sending on a secure channel is indeed pointless, which is the reason you'll find very few soundly designed cryptosystems that do this.
The point is again simple: there are far better options to untrustworthy standards than composing them in the hopes of mitigating their flaws. It's for the same reason that we used to use hash combiners to handle MD5 and SHA1, but now we use HKDF over SHA-2.
>which is the reason you'll find very few soundly designed cryptosystems that do this.
Nearly every secure system I've dealt with (in the military side) encrypted at the network layer (VPN) and they sent encrypted files over that channel.
Yes, because (as I just said), encrypting files mitigates systems problems outside the scope of the secure channel problem. A secure channel doesn't help you if the bag of bits you send down it ends up persisted on an exported, unencrypted filesystem.
That doesn't mean that redundant clientside encryption of files is a sensible feature for a secure channel to have.
The point is again simple: there are far better options to untrustworthy standards than composing them in the hopes of mitigating their flaws. It's for the same reason that we used to use hash combiners to handle MD5 and SHA1, but now we use HKDF over SHA-2.