The root user (UID 0) exists in every Unix or Unix-like operating system. Every process of a Unix operating systems must run as a valid user/UID, independently of system processes, daemons, services or user-initiated applications. Every basic system-process runs under UID 0 (root), and every system-relevant file is owned by that user. For reasons of security, some processes are running as different "users" with lesser privileges than the superuser root. Such users are there for the solely purpose to start services, such as a webserver, a database, the window server and so on. This means, not every user configured on Unix (or macOS) is a "real" user. In fact, most of those system-users can not log-in interactively.
For example a webserver (nginx, apache, ...) will be started by a script running under UID 0 (=root). The webserver-process afterwards drops the privileges to a specific UID (in this case, it could be the user www). www is not a real user and cannot be used to log in to the system interactively.
There are two ways to "deactivate" a (system) user:
- set the user shell to /bin/false (or any non valid-shell)
- disable the users's password, setting it to an invalid, empty or specific value.
On macOS AFAIK a non-valid user has an empty password and a specific property set on the local OpenDirectory server.
Usually, for a request like "is this a valid user" the OpenDirectory service in macOS does a simple check on the requested user and returns true (user can log in) or false (user cannot log in).
It seems, Apples bug was not to check user's validity but to set it to enabled. On already enabled accounts this had no effect, but disabled accounts became valid, enabled accounts. And since a disabled user has no password, an empty password was accepted as a valid option to log in as superuser/root.