Ping has moved from setuid root to setcap
net_admin. Moving from setuid root to setcap reduces the risks if the program exhibits unintended behavior. But that's the same basic mechanism: a process receives extra privileges based on metadata in the executable that it's instantiated from. The concept isn't obsolete, it's being refined.
This is not a new phenomenon: there's a long trend of reducing the amount of privileges conferred to programs. Twenty years ago, executables setuid to a user other than root were common, but (without any change in the OS permission model) those have practically disappeared. Nowadays executables that require the permission to access extra files are made setgid, not setuid, so that if they are compromised, the attacker gains no more than the privileges the program has. The danger of a setuid executable is that if it is compromised, the attacker can replace the content of the executable by a Trojan that will compromise the account of anyone who executes the program.
There is also a long trend towards not making programs setuid or setgid, but rather giving users the permission to execute them via sudo. Sudo has the benefit of finer-grained control (over who can execute the program, and over what arguments can be passed to the program), easier deployment on networks (simply deploy the configuration file
/etc/sudoers, rather than having to be careful about permissions when installing, upgrading and deploying the program), and logging.
Mount needs to be setuid root¹ to let non-root users mount partitions. It can indeed be replaced by other programs such as
pmount (which itself needs to be setuid root) or a service-based mechanism such as udisks.
There are really only two programs that absolutely positively must be setuid root:
sudo. (And any other similar program.) Since they must be able to grant any privilege, they must have the highest privilege in the system.
SSH cannot completely replace su and sudo. SSH can be used as a privilege escalation mechanism, but it isn't suitable for all circumstances. Everything in an SSH session goes through a tunnel. This is not always desirable: you can't pass file descriptors or shared memory via an SSH channel, there is a performance loss (SSH encrypts data, even when talking locally). Also, SSH is useless for a system administrator who wants to repair the system if the SSH daemon has crashed or has been misconfigured.
¹ or setcap
sys_admin but there's no real differences between being root and what you can do indirectly with the
sys_admin privilege — such as mounting a partition with a setuid root binary or mounting something over