In protocol design, why would you ever use 2 ports?

FTP was designed at a time when the stupidity of a modern firewall was inconceivable. TCP ports are intended for this functionality; multiplexing multiple connections on a single IP. They are NOT a substitute for Access Control Lists. They are NOT intended to extend IPv4 to 48 bits addresses, either.

Any new non-IPv6 protocol will have to deal with the current mess, so it should stick to a small contiguous range of ports.

Because FTP allows for separate control and data. IIRC, as originally designed, you could have 3 hosts: Host A could ask host B to send data to host C.

The initial rationale behind this was so that you could:

• Continue sending and receiving control instruction on the control connection while you are transfering data.
• Have more than one data connection active at the same time.
• The server decides when it's ready to send you data.

True, they could have achieved the same result by specifying a complicated multiplexing protocol integrated to the FTP protocol, but since at that time NAT was a non issue, they chose to use what already existed, TCP ports.

Here is an example:

Alice wants two files from Bob. Alice connects to Bob port 21 and asks for the files. Bob open connections to Alice port 20 when it's ready and send the files there. Meanwhile, Charles needs a file on Alice's server. Charles connects to 21 on Alice and asks for the file. Alice connects to port 20 on Charles when ready, and sends the files.

As you can see, port 21 is for client connecting to servers and port 20 is for servers connecting to clients, but those clients could still serve files on 21.

Both ports serve a totally different purpose, and again for sake of simplicity, they chose to use two different ports instead of implementing a negotiation protocol.

FTP has a very long history, being one of the first ARPANET protocols back in the early seventies (for instance, see RFC114 from 1971). Design decisions which may seem odd now made more sense then. Connections were much slower, and performing the connection control "out of band" probably seemed a good move with the available network technology.

The current RFC959 includes a good section on history, linking to earlier RFCs, if you fancy doing a little archaeology...