This was a stronger argument in the past when multi-user/app systems were the rule. If you have only one app running on a box and it can access all of the data which matters, what precisely does getting root give you which getting that app user does not?
Yes, someone could install a rootkit but these days the way to deal with a compromise is to replace the entire system and in either case it's most likely that that process would be initiated by some external clue.
(edit: to be clear, I still don't deploy as root but that's more for other reasons like isolation and I'd be surprised if that was the most pressing security concern on many sites as opposed to things like insecure local services, overly-broad, chainable credentials, etc.)
The ability to go around the host firewall. Accessing data from sub-services that otherwise might run isolated under their own users. The ability to change application source code. Not applicable in all cases, but probably often enough.
My point wasn't that those aren't good but that they're hard enough to do effectively that most places won't see much benefit until they've done a bunch of other things first.
e.g. how many places use least-privilege auth credentials vs. having something like AWS keys or shared database credentials which have access to a ton of shared resources? I'd want to compartmentalize something like that well before changing the UID which code runs under since it's available without any further exploits.
It's certainly possible that something will be logged and it's even possible that someone is actually watching the logs but it's still a gamble that the attacker does something which draws attention: if they have a solid exploit and don't do something which disables legitimate service it's unlikely to be noticed at most organizations.
