But above all, a stable ABI is only needed for proprietary programs which I abhor for not being FLOSS. As a programmer, I really do think the 4 freedoms are important and loathe anything non-compliant.
I've found win32 to be a bit hard to find documentation on sometimes (the official documentation is complete, but sometimes know which hook or function to use is up for debate, stackoverflow has good answers there), but overall it's a very good API that gets out of the way and lets me just build.
I've found a good reference here: https://github.com/mity/old-new-win32api
The message loop (using MsgWaitForMultipleObjectsEx) was somewhere around 20 LOC, to enable all the things that the application had to do (including correct handling of dialogs). I don't count that as getting out of my way.
If it's helpful, I'd like to mention that Charles Petzold's "Programming Windows" has been pretty much the reference for writing Win32 apps since the '90s. (It's the same person that wrote "Code" and "The Annotated Turing".) You probably want the 5th edition as that's the last pure Win32 version; the 6th edition seems to be oriented towards C# based WinRT apps.
I found that Pavel Yosifovich's "Windows 10 System Programming" was an excellent complement to Petzold; it fills in a lot of gaps, and it's quite recent which is nice (there were some bits in Programming Windows that would be dropped if it were rewritten today).
Win32 covers a lot more than xlib, athena and motif. And still I have to resort to porting over bits and pieces from the FreeBSD C library because in a pure win32 project (no msvcrt), things are missing.
The thing is, getting all the details right requires extensive research and a lot of extra nonsense that shouldn't be necessary. For compatibility, accessibility, consistency, etc. Sometimes it's amazing things work at all.
Plenty of details documented across MSDN and Technet, and these old technology called books.
Only masochits do pure C Win32, even back in the Win16 days we were better with OWL, MFC and VB.