The "root" user has been acknowledged as a design flaw even by the team that was making Research UNIX, the people who later moved on to build Plan 9 (which didn't have a root account[0]). That was a late 1980s / early 1990s design.
Even modern systems are attempting to do away with root, or to restrict its unlimited power: reduce the necessity for setuid-root (e.g. via capabilities(7) on Linux[1]), restrict some actions (such as writing to mounted raw disk devices) which shouldn't normally occur at runtime (e.g. securelevel(7) in OpenBSD[2]), the fact that OpenSSH defaults PermitRootLogin to "without-password"; or ultimately - the craziness that is SELinux - the fact that some people are willing to put up with SELinux just to restrict what root can do is IMHO enough of a sign that having root in the first place was maybe not a great idea.
[0]: http://doc.cat-v.org/plan_9/4th_edition/papers/auth [1]: https://man7.org/linux/man-pages/man7/capabilities.7.html [2]: https://man.openbsd.org/securelevel.7
> The way that you mitigate these sorts of issues are very similar to how you’d mitigate the risk of a bad actor getting root access:
I think the most important bit about all five examples I've named is that every one of these is a default (not everywhere, but at least in the upstream project), that administrators have to go out of their way to disable these mitigations, and that (for the most part) all of these are transparent to the normal operation of the system.
Of course you can't fix bad security hygiene, but you can always make doing the more secure thing easier (or in worst case, doing the insecure thing harder).