> I agree, but both points are addressed by sendfile()

I'm talking about send(), not sendfile(). 
Please remember that send() will be used as the default on Windows or when non-regular files are passed to the function. My argument is about introducing an argument to use specifically with send(), not sendfile().
In summary:

sendfile(self, file, offset=0, count=None, send_blocksize=16384):
    """ 
    [...]
    If os.sendfile() is not available (e.g. Windows) or file is not 
    a regular file socket.send() will be used instead.
    [...]
    *send_blocksize* is the maximum number of bytes to transmit at 
    one time in case socket.send() is used.
    """

> Honestly, we should deprecate the whole ftplib module :-)
> More seriously, it's really low-level, I don't understand the point of
> this whole callback-based API:
> FTP.storbinary(command, file[, blocksize, callback, rest])
> Why not simply a:
> FTP.store(source, target, binary=True)

ftplib module API may be a bit rusty but there's a reason why it was designed like that.
'callback' and 'blocksize' arguments can be used to implement progress bars, in-place transformations of the source file's data and bandwidth throttling (by having your callback 'sleep' if more than N bytes were sent in the last second). 'rest' argument is necessary for resuming uploads.
I'm not saying ftplib API cannot be improved: maybe we can provide two higher level "put" and "get" methods but please let's discuss that into another thread.