Depending on how you define "workarounds", glibc is full of those. For example stat(2) is very much not the same syscall now as it was back in the 1990s. In some cases glibc will do a runtime test to see which syscall variants are supported by the kernel and implement workarounds (I even saw a case where this caused a bug in some programs).
stat(2) is not a single syscall. The changes are exposed as new, isolated syscalls (sys_stat, sys_newstat, sys_stat64), with glibc switching internally between them as it sees fit, surprising developers in the process.
This makes stat a great example of the syscall being easier to work with, more stable and more reliable than the glibc wrapper.
Making libc the stable support boundary has all sorts of advantages to an operating system and basically zero downside. Only vanity argues for doing it the Linux way.
Also, Linux is not POSIX compliant and doesn't necessarily care about being. There are several important IO options on Linux that have nothing to do with POSIX.
libc is not intended to be the official entry point in any way or form, and kernel vulnerabilities and workarounds are not meant to be handled by a libc implementation.
That other OSs make libc their official interface is primarily because it's the simplest thing to do when kernel, libc and the rest of userspace is co-developed, as it allows for breaking kernel changes and other fun things that are not allowed under Linux ABI guarantees anyways.
It is not because it is the most secure choice, or that dealing with syscalls is hard (syscalls are easy and safe to work with). It's just that stable ABIs are a lot of work to develop, and this structure is just the simplest for smaller OS communities to develop.