It isn't really hard to understand what is a system call. On the x86-64 architecture, the high level code (like C or C++) is compiled to syscall in assembly. The assembler then converts the syscall instruction into its binary format that the processor understands. The syscall instruction makes the processor jump to the address found in the STAR64 register, a special register of the processor.
With current paging, x86-64 processors have 2 levels of protection: user and supervisor. This is set with flags in the page tables. When in user mode, the processor cannot execute privileged instructions and it cannot access supervisor mode pages. What it can do is execute syscall which makes it jump to a specific address in supervisor mode. At that specific address, the kernel will place an handler to handle system calls. Each operating-system is specific in what it will do in the handler. For example, Linux will look at RAX for the system call number but Windows will look at another register.
Once you understand this, I think your question becomes clear. C and C++ are most often the fastest because they compile directly to syscall. Meanwhile, languages like Python or Java are slower because they compile to intermediate bytecode or are all the way interpreted from code (like I think it is the case for Python). Java is compiled to bytecode that is interpreted by a JVM (Java Virtual Machine) which is itself written in C/C++ and compiled to direct system calls.
It is certain that most APIs on most operating-systems are written in C or C++. But things don't "pass through C". Things are compiled to binary which doesn't care about the high level language you are using. You could be using another language than C or C++ and it could be faster once compiled. It could be higher level and take more time to compile but still be faster once compiled.
C doesn't contain the system calls. 77
C isn't much broader than most other languages out there. The difference is that it is compiled before execution so its hardware accesses can be compiled to a bunch of syscall instructions with some movs to put the right arguments into the registers.
The fact that the os API is written in C/C++ doesn't make the language more broad. For example, on Windows, the API is a set of DLLs. The header associated with a DLL can be included in a C/C++ program that will allow the use of the functions within the DLL. The DLL is then linked against and the linker resolves that, to reach a certain function, the program needs to jump at that certain address. It is mostly done just before runtime by the dynamic linker. The function itself (in the API), is doing syscalls and it is already compiled but the symbols of the functions are kept along with their positions within the code.
This doesn't augment the language itself but it simply uses the current implementation of the language to its full potential by exposing some complex APIs to the language. I think it could not do that with Java or Python because they are most often not compiled. It makes it more complex to expose low level APIs to a language that isn't compiled and that doesn't understand things like linking and system calls.
I don't think the fact there isn't much more system calls with time has much to do with the API. The API is a set of functions the os exposes to drive hardware or do some special stuff that aren't included in the language by default. The syscalls in the meantime are used by the API functions to call the kernel to do some work. API and syscall isn't the same. The syscall numbers don't need to move much because there isn't the need to add much more of them.
This is often understood once you start to get a grasp of the virtual-filesystem present on most modern operating-systems. The virtual-filesystem will present most devices as files to the upper layer of the os. To drive most devices, the only thing you need is read, write and the general ioctl call. You don't need one system call per device. This isn't a matter of reducing the amount of possible combinations. It is a matter of supporting all devices by exposing one common system call that will include support for all devices of a certain type.
The API in itself, is simply there so that the compiler knows what numbers in what registers should be paired with what syscall to have a certain effect on the computer. 77