The premise of the question is mostly flawed. Linux does treat user 0 as the superuser. (It was always user 0; calling that user
root is just a convention.) Capabilities are an additional mechanism that allows non-root processes to receive specific privileges. User 0 normally effectively has all the capabilities, so root remains the superuser.
A process running with effective user id 0 can lose capabilities, but this does not limit its power except in highly controlled environments. Any process that's running with effective user id 0 and can create an executable file and can call
execve can execute arbitrary code with all the capabilities, since
execve does not preserve the process's capability mask when the effective user id is root. (See “Capabilities and execution of programs by root” in the manual.)
It is possible to make an operating system that completely strips access to some capabilities while still using user id 0, by setting the
SECBIT_NOROOT flag during login and making sure that there's no way to gain it back, or by removing capabilities from the bounding set. But that's not how Linux (as in, the Linux operating system) normally works. It's an extra feature of the kernel that is useful for restricted operating systems (for example inside containers).
Capabilities can limit the power of root, but it isn't easy to use them that way and that's no what they're mostly used for: capabilities are primarily used to avoid running processes as root. The Linux kernel does have other features that limit the power of root. Security modules such as SELinux and AppArmor apply regardless of the user id, so it's possible to set up a system where user id 0 can do pretty much nothing (but again, that's not how a normal system is set up). With user namespaces, user id 0 is only the superuser inside that namespace, and this feature is widely used with containers.
FreeBSD offers Capsicum capabilities. I don't know if Capsicum limits the power of user id 0. Once again, the primary goal of capabilities is to reduce the amount of code running with all privileges, not to remove the concept of an all-privileged process.
I don't think any of the other BSD have a capability mechanism. OpenBSD aims to be secure by minimizing the complexity and amount of privileged code. Increasing the complexity of the security mechanisms in order to reduce the amount of privileges that privileged code isn't a free lunch.