Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.
Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.
I wonder if due to C slowly fading away things like syscall
ABI, kernel numbers, etc, will start getting more stable, not just on Windows but on macOS too
There still needs to be a cause for working directly with the kernel interface instead of going via the userland interfaces (libc on Linux, kernel32/user32 on Windows, macOS frameworks) to justify the required effort, and the use cases are basically only DRM, malware, malware detectors and anti-cheat.
Userland DRMs do all sort of nonsense. Kernel anticheats wouldn't use the syscalls, they're already able to call the kernel routines they want directly.
Wine, from the first moment I saw it decades ago, seems to be all about doing the sisyphean tasks no one else wants to be doing. I'm still in awe how they managed to get Wine to where it is today, so if someone can do it, it's the wine devs :)
If you think directly calling Windows syscall is crazy, some applications parse binary code from ntdll.dll to figure out what the syscall numbers actually are, since they change across different Windows versions :)
Other than antivirus software and maybe MAYBE kernel-level "anticheat" slop - who in their right mind does straight syscalls to the kernel?