You need enough data ports so that client IP - client random port - server data port combination uniquely identifies any FTP session (transfer).
The port number serves as a link between a transfer request on the control connection and a data connection. Note that there's no "protocol" on the data connection, that could be used by the client to tell, what it asks for. The port number is the only unique information the server has.
How strong the uniqueness has to be probably depends on the server implementation. I believe most servers require the port to be unique only for that short moment after the client asks for the transfer and before it connects to the data port. So if you have 10 ports and 11 clients asks for a transfer at the very same moment, the 11th is likely to get rejected.
If two clients were to request transfer at the same time, and the server would use the same port number for both (not having any other spare), 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 real life implementations open an unique listening socket, when the client requests the transfer. So when there's no port number free, the server fails to start listening, rejects the transfer, hence it does not even get to having the above problem.
On the other hand, the FTP server built into Bitvise "SSH" server actually supports a single data port only. The server requires a TLS encryption and a session resumption. It uses the TLS session to link the control and data connections.
See also Why does FTP passive mode require a port range as opposed to only one port?
