> assuming the hardware and kernel do support it
Assuming kernel support is doing a lot of heavy lifting there. To put it another way, why is a syscall better than any other stable ABI? If both kernel and stable library are distributed together then why should it be considered different?
A "library OS" like FreeRTOS does exactly that: the kernel is just another library, with functions that you call like any other static dependency. You can only run one process (the OS & your userspace code are that process).
Really the "fully static" side is only seen in practice in RTOSes and similar embedded systems work. Being able to dynamically load more than a single process is just too handy to give up entirely. I don't think the opposite extreme has even been tried (every single symbol in its own .so, even within the kernel), the overhead would be ridiculous.
A syscall may not be inherently too different from any other interface, but a single interface is certainly different from two interfaces.
Kernel support is actually easy: since Linux hardly ever removes syscalls, just build your fully-static executable on the oldest Linux you have, and then deploy it on all of your relevant machines.
The syscalls used by all of your libraries, if they work on that oldest Linux, would work on the newer ones.
In fact, this is why AppImage "Best Practices" includes building on the oldest system. [1]
[1]: https://docs.appimage.org/reference/best-practices.html?high...