Why can Dropbox be super fast compared to FTP?

There could be a number of reasons for this.
The FTP protocol is far from efficient.

1. An FTP transfer needs at least two connections (one for control and one for data) where DropBox may be using just a single HTTP connection. Also the data connection for an FTP session may be opened from the server to your client and if you are NATed this may fail so your FTP client may be trying to connect that way around, failing then trying the other way around.

2. There is a lot of to-ing and fro-ing on an FTP connection. To send a file the client needs to send a minimum of two commands (one to open the data connection and one to start the send) and each time it needs to wait for the server to respond, adding extra latency. As well as these two round-trips per file there are several command-response round-trips for the initial connection - one to send the username, one for the password, and at least one to set transfer parameters (to make sure the server is expecting binary, not ASCII, data). The client may also issue a couple of extra commands to get information back from the server about itself. Dropbox is likely to be using just that one HTTP request, or at most two (one to authenticate, one to send the data).

3. On top of this, depending on what client you are using for FTP transfers (which you don't specify it would be a good idea to edit your question to include that information) it may be dropping the connection after each send operation and reconnecting next time. It is not unlikely that DropBox maintains a connection open for a while for the purposes of long-polling, to react as soon as it can to new data being available that this client should download, so it while it will need to bring up a new HTTP connection to send a file it won't need to re-authenticate.

4. It is not unlikely that the DropBox client is compressing data before sending it (to improve speed and save bandwidth) where your FTP client won't be. So even for larger files (unless they are pre-compressed or encrypted) DropBox, and utilities like it, may be faster than a basic FTP transfer by some margin.

For large files, the first three points above will pale into insignificance compared to the time taken to actually transfer the data, but point 4 may still be quite important. For small files all the extra setup time added by the FTP protocol can potentially be a couple of times longer than the time taken to actually send the data.

As others have mentioned, Dropbox can skip parts of files that have not changed. But also, Dropbox will skip uploading files if it already has a copy on the server side (one that you or anyone else has already uploaded).

So, if you are trying to upload a file that is identical to a file that Dropbox already has, the upload is skipped (and the other linked machines can start downloading it from the Dropbox servers). If you are uploading a file that is nearly identical to another, already uploaded file (it is not clear whether the already uploaded file has to be ‘yours’ or could have come from any user), then it will just send enough parts of the file to recreate it on the server when combined with the file that was already uploaded.

FTP can do none of these things (it is a simple protocol to send and receive streams of data without reference to any other data that is available on the remote end). Tools like rsync and Unison can ‘skip chunks that the other side already has’, but are usually limited to comparing chunks inside files at an identical path in the synchronized hierarchy. Dropbox appears to extend this idea to collections of files (so if you ‘upload’ two nearly identical files, presumably it could arrange to only send one plus enough of a ‘diff’ to re-create the other).