Connecting to a remote server via FTPS (using explicit encryption) fails because the command channel is encrypted. The following output is generated (when uploading myfile.js to example.org/dev2/js):

220 ProFTPD Server ready.
AUTH TLS
234 AUTH TLS successful
USER myusername
331 Password required for myusername
PASS ******
230 User myusername logged in
PBSZ 0
200 PBSZ 0 successful
PROT P
200 Protection set to Private
TYPE I
200 Type set to I
CWD /domains/example.org/public_html/dev2
250 CWD command successful
PWD
257 "/domains/example.org/public_html/dev2" is the current directory
CWD /domains/example.org/public_html/dev2/js
250 CWD command successful
PASV
227 Entering Passive Mode (185,182,56,157,140,103).
STOR myfile.js.new
150 Opening BINARY mode data connection for myfile.js.new
425 Unable to build data connection: Operation not permitted
PASV
227 Entering Passive Mode (185,182,56,157,139,175).
STOR myfile.js.new
150 Opening BINARY mode data connection for myfile.js.new
425 Unable to build data connection: Operation not permitted
PASV
227 Entering Passive Mode (185,182,56,157,140,61).
STOR myfile.js.new
150 Opening BINARY mode data connection for myfile.js.new
425 Unable to build data connection: Operation not permitted
DELE myfile.js.new
250 DELE command successful
QUIT
221 Goodbye.

The root cause seems to be that NAT firewalls block such operations when the commands channel is encrypted. Given the omnipresence of NAT firewall these days, this largely voids FTPS support. The proper fix would be to add a CCC command so that the commands are passed in plaintext, but the data (=transmitted files) remains encrypted. This way NAT firewalls will not block the transfers.

(Note: when enabling "Encrpyt Only Authentication Process" this error does not occur, but that's not even a workaround since that means the files are passed in cleartext, including any passwords inside the files.)