That's how the FTP protocol was designed to work in the passive mode. It was probably not a good idea, as I do not think that this model was ever repeated again in any other protocol (and that's true even more so about the FTP active mode). Wikipedia FTP article mentions that FTP was designed this way because originally it was not intended to operate over TCP/IP (FTP originated in 1971).
On the data connection port, there's no protocol. All that the server knows – the only thing that carries any information in that connection – is the port number you connect to.
If you were to connect to the same port every time, the server would not be able to tell what file you are connecting for. The port number serves as a link between a transfer request on the control connection and a data connection – the port number is contained in the response to the PASV command.
If two clients were to request a transfer at the same time, when the server accepts a connection on a single port, the server would not be able to tell what file to transfer. Of course, the server could use a client IP for the decision (actually many FTP servers do validate that the client IP matches the IP used on the control connection, for security).
But this would not work for:
- Multiple connections from the same machine (most FTP clients do support parallel transfers/queues and you can actually run multiple different FTP clients on one machine);
- Connection from different machines within the same (corporate) network, as those have the same external IP.
Partially copied from my answer to Why does FTP passive mode require a port range as opposed to only one port? on Server Fault.