UNIX is the C language runtime, so to speak, so naturally libc is THE system interface.
It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX.
Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.
I do not dispute that it made sense during early days of UNIX. But today we write system software for these operating systems in many languages other than C. Maybe it's time to reconsider the dominant libc position instead of reinforcing it further?
Linux has successfully paved the way and demonstrated its practicality. Yes, it made certain unfortunate mistakes along the way, but OpenBSD (or any other OS) can learn from those and provide a better solution.
Every other operating system does exactly the same in regardless to abstracting syscalls, regardless of being UNIX clone or not, GNU/Linux is the exception, not the rule.
If you mean a C based OS ABI, there are many other alternatives, like on managed OSes, IBM and Unisys surviving mainframe and micro computers, OS IPC like COM/XPC/AIDL/FIDL/D-BUS.
It only became something else, when C got standardised, a tiny subset of it landed into ISO C, grew beyond UNIX, and the rest of the UNIX API surface landed at Open Group's POSIX.
Obviously on the UNIX world nothing changed, until GNU/Linux came into scene and decided to act in another way, due to being GNU ecosystem + Linux kernel combo.