HTTPS all the way. Anything based on FTP is nearly 45 years old and comes with a ton of baggage from the era when people were just figuring out this stuff. It's not an accident that HTTP triggered one of the biggest information revolutions in human civilization while FTP barely manages to survive as used protocol. There is nothing that you can do with (S)FTP(/S) that you can't support with HTTP(S). The converse is not true.
I don't really understand a lot of the answers here since they center around the browser. HTTPS is used for much more than the browser. On the other hand, FTP is currently supported by major browsers.
As stated by other responses, the connection security between HTTPS and SFTP should be equivalent. The security problems with FTP (secured or not) are related to the overall design of the server implementation. There is (in my experience) always the concept of a directory that contains files. Unless you disable these features (assuming you can), users can both read and write to these directories. Even if all the permissions setup correctly, there are many examples of FTP servers having authorization flaws that allow users access to more than what they should have. Files are stored in the clear in these directories unless you use an additional layer of encryption. Where I work we are required to use PGP file encryption with SFTP for this reason.
EDIT: I should add that since SFTP is based on SSH, it (AFAIK) requires the creation of a system account on the server which opens up a huge slew of potential problems. If you are going to SFTP on the public internet, you should at the very least have a dedicated server strictly for this purpose and treat them mush like you would treat public HTTP servers in a DMZ. That is, connections coming are granted very little trust.
You can absolutely set up a web site that supports the functionality of FTP i.e. allowing if you list of the URIs that can be accessed. But you need to actually make an effort to do this. With FTP based tools, you need to go out of you way to remove these features. Additionally, the HTTP based solution allows for authentication and authorization at every step. So if you allow the user to list files they shouldn't see, they don't automatically get the right to retrieve them. If all you want is to let them POST a document, then just do that and don't support anything else.
EDIT: The statement that SFTP has nothing to with FTP is making a distinction without a difference with regard to the core of my argument. SFTP and FTP share almost the exact same meaning for the following commands:
bye (exit, quit)
That is, the basic "file transfer" design i.e. a directory on a system that you manipulate remotely is functionally equivalent. It's this design that is the issue. However I should note that SFTP also provides the following which are fun to ponder from a system security perspective:
! (drop to a shell)
If you are using SFTP and exposing it to the internet, you better be sure you have these remote user accounts configured properly.
EDIT: Given the apparently lack of understand of the risks of SFTP here's some discussion about the kinds of things you have to consider when you give someone a server account (as required for SFTP): https://forums.cpanel.net/threads/sftp-ssh-really-concerns-me-security.25572/
I should probably qualify this a little. SFTP is a perfectly good way for a known system user to move files back and forth to a system. However, if your goal is to allow untrusted or semi-trusted users to send you data, you are most likely violating the Principle of Least Privilege and opening up a large number of vectors of attack unnecessarily. Given how trivial it is to implement this functionality securely with HTTPS and avoid these issues, it makes no sense to choose SFTP if HTTPS is an option.