I think it's worth pointing out, in case it's not clear to people, that the SUID file mode bit is not synonymous with elevating to root privileges. Many programs use SUID or SGID to switch permissions to non-root users and groups. For example, games often use SUID or SGID so they can write to a shared scores files owned by, e.g., a "games" user or group. In such cases root privileges are never involved, not even to pivot.
I prefer "SUID" to "setuid" because setuid is also a syscall and in fact the setuid syscall is more often used to drop privileges. In fact, in order to use setuid to elevate privileges a process needs to have already had that UID/GID as its saved UID/GID. Also, with all due respect to Douglas McIlroy (who of course is one of the fathers of Unix), the patent by Dennis Ritchie mentioned elsewhere refers to "SUID", not "setuid". Wikipedia treats SUID and setuid synonymously, too, but this is one of those times where Wikipedia should be a little more pedantic, notwithstanding the popular usage of "setuid" to refer to both concepts; especially because in practice they're typically referring to completely opposite changes in direction of privileges.
That's because direct i/o and device access for VGA card manipulation requires root access, it's not directly relates to file permissions. Same with X11 servers for the longest time (until the kernel started providing APIs for this)
Minor nitpick from someone who wrote device drivers at a FAANG whose name starts with A and who is not based in Seattle: devices can have a presence as a device special file in the filesystem, but they might be not represented in the filesystem also...they might be hiding down some hardware bus, for example.
On x86, i/o permissions could easily be delegated to a user-level task; although you'd need some mechanism to request/grant the access, as you probably wouldn't want to allow all programs to access the i/o ports. You'd probably need a mechanism to disable the built in VGA console as well.
