Does FTPS (FTP+S) offer better security than SFTP on the server side?

From the security they provide in theory FTPS and SFTP are similar. In practice you have the following advantages and disadvantages:

• With FTPS client applications often fail to validate the certificates properly, which effectively means man in the middle is possible. With SFTP instead users simply skip information about the host key and accept anything, so the result is the same.
• But users and admins with more knowledge could make use of SSH keys properly and use these also for authentication which then makes SFTP much easier to use compared to using passwords. And if passwords are forbidden at all then this is also more secure because brute force password attacks are no longer possible.
• FTP uses dynamic ports for data connections and information about these ports is transferred in-band. This makes already plain FTP (without TLS) a nightmare when firewalls, NAT or similar is involved. With FTPS (FTP+TLS) this gets even worse because due to the encryption of the control connection helper applications on the firewall can no longer find out which ports need to be opened. This means that to pass FTPS you would need to open a wide range of ports which is bad for security(*). SFTP is much better because it uses only a single connection for control and data.
• FTP(S) servers often provide anonymous access and SFTP servers usually don't. Several FTP(S) servers also offer pseudo users, i.e. users taken from same database or similar which are not real users on the system. If you have proper users only anyway this does not matter.
• SFTP uses the SSH protocol and you have to configure the system properly to only allow SFTP access and not also SSH (terminal) access or even SSH forwarding. With FTP this is easier because FTP can do only file transfer anyway.

(*) Several comments do not really believe that having a wide range of ports open is bad for security. Thus let me explain this in more detail:

• FTP uses separate TCP connections for data transfer. Which ports are used for these connection are dynamic and information about these gets exchanged inside the control connection. A firewall which does not know which ports are in use currently can only allow a wide port range which maybe will be used sometimes FTP.
• These ports need to allow access from outside to inside because in FTP passive mode the client connects to some dynamic port on the server (i.e. relevant for server side firewall) and for FTP active mode the server connects to some dynamic port on the client (relevant for client side firewall).
• Having a wide range of ports open for unrestricted access from outside to inside is not what somebody usually considers a restrictive firewall which protects the inside. This is more similar to having a big hole in the door where a burglar might come into the house.
• To work around this problem most firewalls employ "helpers" for FTP which look into the FTP control connection to figure out which ports need to be opened for the next data connection. One example is ip_conntrack_ftp for iptables. Unfortunately with FTPS the control connection is (usually) encrypted so these helpers are blind and cannot dynamically open the required ports. This means either FTP does not work or a wide range of ports need to be open all the time.

The sysadmin raises a valid point. (but his interpersonal skills might need work)

SSH is a complex protocol, and openssh implements a lot of functionality. All this functionality offers attack vectors, and it is very hard to be sure that none of these vectors are exploitable.

Even if openssh is without bugs (which it isn't), knowing about all the right possibilities to close off unwanted functionality, and understanding how these options might interact takes significant effort in itself. And these interactions might change from version to version.

As an example, consider the following sshd_config snippet, which has the intention of limiting certain users to SFTP-only (we even thought of locking them to their home directories):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp

And sure enough:

% ssh somehost
This service allows sftp connections only.
Connection to somehost closed.

But wait...

ssh -N -L 9000:localhost:80 somehost

Whoops, I now have forwarded port 80 on somehost to port 9000 on my host. That means we can connect to port 80 on somehost as if we are coming from localhost. Probably not a big deal for port 80, but what about services that only listen on localhost, such as administrative services or databases?

And that's just TCP forwarding. At the very least, SSH also allows X11 forwarding and SSH-agent forwarding, and I don't even know the implications of those two.

We do use ssh/sftp a lot, because for our situation the advantages outweigh these risks. But it is a valid concern that should not be taken too lightly. We ended up with this for use cases where just sftp is enough:

Match Group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    AllowAgentForwarding no
    ForceCommand internal-sftp

We hope this is adequate to ensure just sftp access, but we can't be completely sure. (suggestions welcome ;)

Both protocols have advantages and disadvantages, as explained very well in this comparison article.

This said, since the question is specifically regarding security, there are a few considerations that should be taken into account when choosing which protocol is best in certain specific conditions.

FTPS and FTPES use SSL or TLS to encrypt the control/data connections. The main advantage of these secure channels is that they use X.509 certificates, which contain much more information that a simple key pair (host name, email address, organization name, the ISSUER (CA), ...) and are therefore a lot easier to validate. But:

• SSL 1.0, SSL 2.0: deprecated long time ago (insecure)
• SSL 3.0: recently deprecated because of POODLE
• TLS 1.0: no longer acceptable for PCI compliance
• TLS 1.1: lacks some of the extensions of TLS 1.2, and has limited client support, no reason to use it
• TLS 1.2: current standard, so far considered secure/safe

And the above only covers the channel(s) encryption protocol, then there are safety considerations regarding the FTP protocol itself. The SITE command, for example, has been used over and over to perpetrate attacks, and the inherent design of the protocol itself requires to open and NAT multiple ports on your firewall (which can become a nightmare to manage). Furthermore, most firewalls are not able to properly NAT FTP-data connections unless the client requests and the server allows CCC (Clear Control Channel) which defeats part of the security by running the control connection unencrypted.

On the other hand we have SFTP, which is a subsystem of SSH. The main challenge here is that SSH keys are "just keys", they are not issued by a CA and no issuer statement or key-chain is included in them, therefore SSH server keys have to be expressively trusted by the client.

Someone may argue that configuring an SSH server to only allow SFTP (no shell, no commands, no forwarding tunnels, no X11) may be difficult. That actually depends: if you're running Linux and OpenSSH that might be true, but there's a plethora of SSH/SFTP servers out there that make this kind of configuration a breeze, so I wouldn't necessarily list this as a potential flaw, unless - as I said - Linux/OpenSSH are used.

A couple remarkable side advantages of SFTP, though, include:

• ECDSA key exchange: a 521-bit ECDS(X) key is equivalent to a 15,360-bit RSA key in terms of security, and requires 9 times less CPU cycles for signature calculation
• Inherent forward secrecy: the SSH protocol can renegotiate the actual channel encryption key in-session, and provides inherent forward secrecy, as opposed to any SSL/TLS-enabled server that require additional configuration work to accomplish this

So, ultimately the choice is really up to you guys, but the argument that the sysadmin was making is blatantly invalid, and if there is an existing SFTP server that is well configured (as explained) then there is no reason (especially no security-related reason) to switch to FTPS (or FTPES).