At least at places I've worked, terminating the logger would cause a security incident, and the central logging service have some general heuristics that should trigger a review if a log is filled with junk. Of course with enough time and root, there's ways to avoid that. But that's also usually why those with root are limited to a small subset of users, and assuming root usually requires a reason and is time gated.
That still leaves highly visible log traces if you’re following most security standards (required in .gov) since you’d have the logs showing them disabling the forwarder. The difference here is that this was like an attacker but had backing from senior management to violate all of those rules which would normally get someone fired, if not criminally charged.
That is a very serious design flaw, but I also believe it is a flaw that is addressed by SELinux. (Perhaps someone with a knowledge of SELinux can offer some input here.) That said, I'm not sure how widespread the use of SELinux is and doubt that it would help in this case since the people in question have or can gain physical access.
Not without a reboot though, and while I haven’t done that, it should be possible to protect selinux ‘s config itself with a policy, requiring boot loader access to bypass, at which point you’re dealing with a different risk level.
I’ll agree that Linux security is quite limited and primitive if compared with, say, a mainframe, but it can be made less bad with a reasonable amount of effort.
That’s a big rabbit hole, reading about RACF is a good place to start.
The short answer would be that mainframes come with RBAC from design, unlike Unix, which has a different security model from conception and then had rbac added on top of it in some cases (such as selinux).
There is no legitimate justification for this request.