If you're going to the effort of extracting detailed audit information from a system and then having to decide whether each audit event is relevant or not, why not just write seccomp-bpf filters and landlock rulesets to restrict what each process can do in the first place? And/or as a simpler option, implement sandboxing of Systemd units with easy-to-use configuration of file system access restrictions, system call filtering, resource control, etc.
This is indeed a valid approach, yet I think these methods can be complementary. Sandboxing will never entirely prevent bad things from happening (the iOS exploit scene is a good example of this); it merely makes an attacker’s life more complicated. What we aim to provide are meaningful security logs that can be used to detect ongoing or past compromises (if logs are archived). Imagine the following simple security incident: your SSH key or credentials are leaked/stolen and someone uses them to log in and start using your server for any purpose (install malware, serve files ...). Just having sandboxing in place would be fairly useless, as SSH would be allowed to do almost anything. Moreover, having such a source of logs for post-mortem analysis by incident responders is very valuable, as they can help you understand in detail what was going on. This is why, in my opinion, both sandboxing and monitoring are valuable when used together.
A small remark on the sandboxing configuration aspect: I personally think it is not trivial to achieve properly, as it requires very precise scoping of every single application/service running, and this needs to be maintained across software updates to prevent breaking functionalities. I personally use such sandboxing on my workstation, and even on a single machine, it can sometimes be a burden. I can't really imagine maintaining this across a whole heterogeneous infrastructure of servers and services. I am pretty sure it is possible, but it is not easy and probably not doable in terms of resources for every sysadmin team.
