Is there any good reason (except "GCC is better") to use the MinGW win32api/headers/libs with LLVM/Clang. Suppose that in two to three years, Clang has matured enough (in C++0x and performance) that it's a competitor/replacement and has its advantages over MSVC like GCC does on some accounts. Why on earth would one want to avoid using the MS library and header implementations of the win32 API, which is freely available in the form of the Windows SDK?
One reason for the MingW header files to exist is certainly copyright: while they are "free as in beer", you are not allowed to redistribute them. Neither could the LLVM authors redistribute them, instead, every LLVM/Clang user would have to download them on their own. So it would be reasonable for Clang to provide a set of header files, and it would then be reasonable to use the MingW code as a starting point.
In addition, another reason for the MingW header files to exist (IIRC) is that the SDK headers use C extensions that were not supported by gcc. They may be supported now, so that reason may have gone.
This answer is for 2018, and as far as I know it applies to all versions of Windows since Vista (updates providing).
The short answer is: you can't. Or more precisely, you can, but you will be pulling teeth every step of the way, spending countless man-hours fighting to get the API to work for you rather than against you, and it's simply a question of whether that's worth it to you.
The Windows API is by design going to be nightmarish to use without MSVC, because Microsoft wants you to use their entire development solution, and they don't give you a choice to avoid Visual Studio if you use their libraries. While it may seem convenient and sensible that the OS ships with the Windows SDK for free, it won't work without the C standard library, which is provided as a download from Microsoft. When you download this library through the installer, you'll find that Microsoft's UCRT depends on headers only found in the Visual C++ package, which is a 600MB+ download and consumes over 2GB when installed. And after all that, your compiler will default to choking on Microsoft's custom dialect of C, which isn't C99 but uses line comments and has countless other traps specifically designed to trip up sane compilers.
The above also doesn't even scratch the surface of legal that your team might have to delegate to cost even more money so you can figure out what's redistributable and under what terms. MinGW's libraries solve not only the legal concerns for the standard libraries (thanks to the GPL exception clause), but also make it painless to use in actual ISO C/C++.
My experience with this problem stems from a project I'm working on to develop a codebase using a unified LLVM-based build process. Everything works well enough on Linux and macOS, but on Windows without MinGW it has taken me days to failingly sort through this, and I haven't even gotten into the hiccups that there will inevitably be during linking with LLD. It's just not worth it to use anything Microsoft unless you're using MSVC, because Microsoft says go all the way or go home, and they put their code where their mouth is with that.
One reason might be that every SDK you can download only works on certain Windows versions. You can still download older SDKs that also run on older Windows versions, yet these are missing all the newer features added by later Windows releases.
Compared to that mingw64 runs on every Windows from XP SP1 to the latest Windows 10 and it offers all the features that were added in between. Such a universal SDK is not offered by Microsoft, every SDK is limited in supported Windows hosts, supported Windows deploy targets, or supported feature sets.
Another reason is that the SDK Microsoft offers can only be installed on only works on a Windows system, yet with mingw you can cross-compile to Windows, that means the system you use to build your Windows executable does not have to be Windows, you can as well build it on a Linux system.