Why is the primary admin UID 501?
Many Unix systems start handing out UIDs to users at some particular number. Solaris will give the first general purpose user UID 100, on OpenBSD it's 1000, and on macOS it appears it's UID 501 that will be the UID for the first created interactive user, which is also likely a macOS admin user (which is not the same as the root user).
The accounts with lower numbers are system user accounts for daemons etc. This makes it easier to distinguish interactive "human" accounts from system services accounts. This may also make user management, authentication etc. easier in various software. YP/NIS, a slightly outdated system for keeping user accounts (and other information) on a central server without having to create local users on multiple client machines, for example, has a MINUID and MAXUID setting for the range of user accounts that it should handle.
On some Unices, a range of the system service accounts may be allocated to third-party software, such as UIDs 50 to 999 on FreeBSD or 500 to 999 on OpenBSD.
All of these ranges are chosen by the makers and maintainers of the individual Unices according to the expected needs of their operating system. The POSIX standard does not say anything about these things. The lowest and highest allocatable UID (and GID) is often configurable by a local admin (see your adduser manual).
Most Unices reserve UID 0 for root, the super-user, and assigns the highest possible UID (or at least some high value) to the user nobody (Solaris uses UID 60001, OpenBSD uses 32768, but UIDs may be much larger than that).
(See comments about UID 0 always being root (or not), which is a slight digression from this topic)
Update: The OpenBSD project recently rejected the idea of randomizing UID/GID allocation.
For distributions which follow the LSB, they allocate UIDs and GIDs 0-99 statically. UIDs 100-499 are allocated dynamically, but these also are for the system, and not for login accounts.
For example, printing daemons like cups tend to be allocated their own user account. So if a vulnerability in the daemon is exploited, the daemon is not running as root with full power over the system. (Nor does it necessarily have the power to interfere with other daemons).
On more recent Linux distributions, the system range is extended up to 999.
This would leave UIDs 500 upwards (or 1000 upwards) for login accounts.
Debian additionally has a static allocation for UIDGID 100, although I can't imagine that deviation causing any particular problem.
It's easy to imagine another system with an off-by-one deviation, which additionally reserves UID 500. (I assume this would still be compliant; I can't imagine all the Linux'es have been violating the LSB for this long, without it being updated).
The first login account doesn't have to be either an admin account nor the primary admin account. Systems don't necessarily use sudo (particularly if they pre-date it :). You might say the "primary admin account" is root in that case. Other than that, *nix and general-purpose Linux distributions don't recognise a specific "primary admin account".