You might need that when you want to reimplement Linux, the Joyent team did that on their OS (derived from solaris) so that user can run linux binaries on a solaris kernel (so thay have dtrace, zfs, mdb, ...) Bryan Cantrill did a bunch of conferences on that (one here: https://youtu.be/TrfD3pC0VSs)

The idea behind is that Linux is only a list of syscalls, if you are able to reimplement them, you reimplement linux, you don't need anything else. On the contrary if you want to reimplement a BSD you need to reimplement their libc (and perhaps some other libraries)

I had cause to consult a syscall table (not this one, a correct one, forget where I found it) when doing something or other with fasm. fasm's macros are pretty dang advanced...I remember having argument length checking and rudimentary type checking as well. Then I got done yak shaving and remembered that programming in asm sucks.

But yeah, it's for writing your own syscall wrappers. Something not exported by libc, or more likely if you're not using libc.

Sometimes, yes, you'll need to write your own syscall wrappers. For example, there isn't a gettid (get thread ID) function in Glibc, but you can work around this by calling the syscall directly.

The other case where this is useful is if you're wanting to write userspace assembly without calling a C library. This may be especially useful when you're writing a compiler, or if you're trying to write small shellcodes for some reason.

Or to try making more sense of some libc implementation. The syscall stuff in glibc and musl both have a good bit of preprocessor voodoo to make syscalls feel more like function calls.

Implementing a programming language without any dependencies to C code for example.