Realistically speaking, most applications you would want to allow others to run as sudo were never designed to withstand such attacks and will likely fail in the hands of a competent attacker that is free to use any command line, feed any input etc.
I figured it was so you can identify the user who ran the command in an audit, instead of everyone just appear as "root"
This goal can still be performed if auditd is enabled. The transition from non-root to root is tracked with the right rules in place. In my opinion it is best to rely on auditd and immutable after being tested rules as there are many ways to elevate privileges and many ways to improperly configure or bypass sudo. Auditd has a plugin to log directly to syslog and/or forwarded to ELK, Splunk or other tools. Auditd is also important when applications are exploited and someone then uses a privilege escalation vulnerability otherwise the person will just run it again after the machine/VM/container is re-imaged. Sudo was never intended to be a security control as much as it was to give a non sysadmin the ability to restart something or launch an on-demand process that required root or other accounts despite people using it in their documented controls. Many people will disagree with me on this as has been the case since the inception of sudo.
One caveat being auditd with the most useful rules in place can get rather noisy and more to the point, costly in terms of storage and/or Splunk license. It comes down to the priorities of an organization or business.
But I do recall it being a lot more pleasant tracing who ran what sequence of commands, on a host used by many people in concurrent workflows, when it's sudo over su.
It's also been some ~20 years since I've been in a role that required I do this so I (most probably) have forgotten a lot.
Very limited!