Is irrelevant and archaic for many, many servers (99%) of ones I've worked on last 20yrs (web/internet servers vs file/print/lan type servers.
The only accounts who can login and get a shell are the same set of accounts who can su root to almost every server I'm involved with.
On everything I'm responsible for, it's assumed that if you've got shell or if you've got permission to upload executable code, you've got the ability to get root.
I'm prepared to keep on top of server security enough to protect against remote-root exploits (with reasonably short zero-day exposure times), but there's no way I'm going to be able to keep every little utility shipped with a useable linux distribution up-to-date and secure.
If Tripwire or Snort or the logfiles show unexpected filesystem changes, we reimage the OS and restore the data from backups.
When you have DBA access to production databases, lack of root does not stand in the way of doing evil.
It does stand in the way of using message logs to troubleshoot, checking contents of /proc to determine which directory a process is running from, tuning TCP parameters to maximize data transfer rates without nagging the sysadmins, etc.
(For evil-genius-DBA's bonus points for doing that via the database instead of the shell and censoring traces from the db logs too...)