- provide Windows headers, to keep those DWORDs etc. defined
Yes, but so does MSVC.
MSVC as in Microsoft Visual C++? It only provides a C/C++ runtime. The headers come from the Platform SDK. In any case, here Winelib provides them, probably slightly altered so they'd built better on gcc.
Visual C++ ships with headers and a compiler. Anyway, there's no advantage to winelib as a build environment compared to MSVC or the Platform SDK, assuming you are able to use one of those, except for the ability to port to architectures other than x86, x86_64, and arm.
- implement Windows APIs in terms of Linux as much as possible -- to keep those
CreateFileWs going, to avoid changing every single 'Sleep' to 'sleep' "just because".
Winelib doesn't do that. It uses the same implementation of the Windows API that is in Wine.
Sleep and CreateFileW are Windows APIs. I want them implemented for my C code to link to. Internally, they call into libc or Linux syscalls. How is Winelib not what I want?
Wine's CreateFileW does path mapping to simulate a Windows filesystem, regardless of whether you're using winelib. It's not a thin wrapper around Linux API's; it's exactly the same wrapper you get if you run a normal Windows program.
Because it's the same API implementation, it doesn't offer any advantage over running the same code compiled with Microsoft's C/C++ compiler (which according to rumor is faster and has a better optimizer), while there is a significant disadvantage in the form of the work it takes to make that code build correctly.