Linux considers syscall API stable and there's a pretty hard rule of not breaking user space.

Linux does, yes. MacOS and BSDs do not. (Neither does Windows - but so far as I can see, Go doesn't try to invoke the NT APIs directly there.)

Stability is guaranteed on userspace API level - e.g. libc. So well-behaving apps are supposed to just use that, and let it handle syscalls. But Go doesn't.

I am not all that familiar with kernel/low level programming, but wouldn't the C API/library internally use syscalls as well? If a C program is written with a dependency on a syscall, and this syscall is changed. Does the code still work after, or does it need to be recompiled with an updated compiler?

The compiler doesn't really play a role in this. If a syscall changes, then you'll need to change the arguments in the C code that invokes it.

The system libraries like libc themselves use syscalls internally, yes. But on those platforms I'm talking about, they're maintained by the same people who maintain the kernel, and both components are versioned together. So they can go and change a syscall, and then also make the corresponding change to libc (without changing the latter's public ABI), and ship the updated versions together as the new OS release. Well-behaved apps dynamically link against libc, so the change is completely transparent to them.

On Linux, different people maintain the kernel and libc (and, in fact, there's no single officially blessed libc - this is one case where the old adage that "Linux is just a kernel" is in full force). Consequently, the interface between the two has to be treated as a public API, with stability guarantees.

The system's C library would use the syscalls directly and the application would use the C library routines. So if/when the OS updates the syscall ABI, it would also update the system's C library to use the new syscalls, and the application would continue to use the stable C library API and get the new syscalls under the covers automatically.

FreeBSD also doesn’t break the ABI on major versions.

That's good to know, but it still means potential breakage every 2 years on average.

Historical accident, it is all a matter how libc of a specific compiler was implemented.

I would rather say, it's a matter of having libc and kernel developed as a single package ("base system") by the same people, and versioned together, versus having the kernel and the userland separate.