While the Windows API can be pretty clunky and has a ton of leftover cruft, and the UI-related APIs aren't too great thanks to being compatible with Windows 95

While the Windows API can be pretty clunky and has a ton of leftover cruft, and the UI-related APIs aren't too great thanks to being compatible with Windows 95 (use a toolkit if you want controls), it'd be really hard to argue that any of those (except maybe TempleOS; I haven't looked at it) are any more sane than Win32. You get pretty unified support for async notification through IOCP, which can be used for sockets, files and a few more things. On most of the systems you listed you'd get some flavor of kqueue at best, and probably only for sockets. On the NT side of things you have the handle system, which serve the same purpose as file handles without pretending that "read", "write", and "ioctl" are the only operation any of them will support (plus socket operations, if you want to include those). It also provides the ability to transfer them between processes (with access control!) and place them in a (semi-)global namespace without having to muck around with the actual filesystem. Not to mention basic operations like reading information about a process doesn't involve having to parse text that can contain semi-arbitrary strings (/proc/<pid>/stat contains the filename near the start, have fun) I can't say I like Windows as an OS, but API-wise? Not fantastic either, but compared to every other major desktop OS/kernel it's a saint, and provides more functionality. In the context of complex 3D games; if you need to do something like transfer 1GB of data from disk to GPU memory as fast as physically possible, you have to care about this.