I can't say what they had in mind when typing `systemctl`. Even they couldn't. Because of the delay in the shutdown to cleanly stop the services, they had already forgotten that they just exited a SSH session and thus the connection between the machine being dead and typing `exit` was not obvious.
Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).
GP's point was more that you shouldn't be able to casually do "systemctl exit" in a standard shell session. All privileged operations should require a sudo. One might be tempted to just do a full "sudo shell" to perform all systemctl operations, but GP's point is that many of the "observation" actions don't require sudo in the first place!
In the end, the user being able to accidentally run "systemctl exit" may be indicative of a policy issue (ie don't allow root logins).
All sudo actions on my machines are logged to a remote syslog server (and locally to /var/log/auth.log, which is rotated, compressed, and kept far longer than other logs). That certainly used to be standard. You can't log on as root, you have to log on as your own user and elevate to root (even if that's all you do with sudo), so there's a trail there.
This article suggests there are ways for programs to issue unaudited commands with elevated privileges to systemd.
"Systemd has a D-Bus interface that people can use, there's hardware events that may trigger a reboot, there are various programs that may decide to ask systemd to reboot the system, and under some circumstances systemd itself can decide that a particular, harmless looking process failure or 'systemctl' transaction actually will trigger a reboot through some weird chain of dependencies and systemd unit settings"
Complaining about systemd is as old as systemd, and borders on a religious war, a proxy towards "modern linux" and "old school unix" methods.
Maybe it was `systemctl status`. Maybe it was intended to be a `reload` (which would require elevated privileges).