HTTPS and SFTP when used properly are equally safe. The underlying encryption algorithms in practice are both functionally equivalent -- neither can be broken in practice by directly attacking the cryptographic protocols. However, in practice with non-tech savvy users, HTTPS is slightly weaker in my opinion.
There are attacks on both that can be launched on uncareful, non-tech savvy users. The attack on SFTP as Rell3oT said is that typically you initially do not know the public key of the SFTP when you first connect, and remember it for all subsequent connections (though the SSHFP DNS record defined in DNSSEC could solve this issue, but are not currently widely-used) . This means an attacker who rerouted internet traffic initially to their fake sftp server could capture your data, if they targeted the attack on someone connecting to the sftp site for the first time from a computer (that does not have the public key saved). This attack cannot happen on subsequent connections. However, with https there are several more potential attacks introduced that non-tech-savvy users could get tricked into.
The user may not go to https://your-secure-file-transfer.com but instead just type your-secure-file-transfer.com into the web browser (which by default goes to the http version). An attacker could wait for this case, and then capture this traffic and redirect it to their forged copy of that site; stealing the authentication information/financial data. (Yes a similar thing could happen with sftp being replaced with ftp; but as it's typically done in a separate app that saves the connection information this seems less likely -- to go to the ftp version the user typically has to manually type in a different port number). You can fix this by requiring the site to have HSTS enabled. Unless they are careful about the URL bar displaying https, the user may not notice they are at an http site or a different URL. HSTS is only enabled on a small list of major websites by most browsers. Most of the time, it gets enabled in a web browser after successfully visiting the HTTPS site the first time (where there is a header to remember that this site must always connect over https); giving functionally equivalent security to SFTP.
A non-tech savvy user's web browser is less secure than your standard SFTP client. Users often install various browser extensions that have the ability to access all your internet activity to get some sort of functionality. This added-on functionality may come with a secret attack; e.g., steal session cookies, information entered on forms (like their password), etc that eventually gets sent back to the client author. The CA (or intermediate CA) could be compromised at any date and attackers could get browser-trusted certificates that allow them to spoof your https without detection. This differs from SFTP again, where the sftp client remembers the public key for the site that it has seen before and alerts you if it has changed. (Web browsers will not do this; certificates are allowed to change as long as they are properly signed. Again this is not likely to change any time soon, as load balanced web servers generally all have different signed certificates.
All and all I'd say HTTPS is slightly weaker in practice than SFTP; while both are equally secure based on their cryptographic merits. If you train your users to check that https is present and at the correct domain, and additionally instilled some paranoia about using browser extensions on their work computers (or suggest using browsers private mode typically with few extensions installed) it will be roughly equivalent (assuming you have the site setup correctly with HSTS/secure http-only cookies, etc).
