So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.
Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.
Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard.
Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that.
Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software.
Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet.
You're making fun of unicorns, but treating 'POSIX' like a magic word.