Hm, this is only the theory.
In practice, lots of modern NT syscalls are directly or at least quite closely modeled after their Win32 equivalent. Even more so when they have been introduced after the end of the Windows Consumer vs NT split - but even before that, NT was already very close to Win32.
And Win32 has always been special for NT. And Posix & co has always been "special" in the other way: even when the idea of having subsystems was already decided (at first it was mainly for OS/2 vs Windows API), the question was raised whether to implement the Posix API in a subsystem or layered on top of another subsys API (like Cygwin is today). The paper advocating for the subsystem is available in the WRK, IIRC (quite a poor paper with bad arguments IMO, but it shows that the question has been raised).
Actually the traditional NT subsystems were not even able to do WSL, and the most important work to get it was not the legacy of the Posix & co. subsystems, but a project to be able to virtualise different versions of Windows userspace on a single NT kernel (indirectly, it first leads to the Android subsys attempt, which got cancelled and then morphed to the WSL we will get).
When you look at the WSL architecture (and compare with Windows NT + Win32 architecture) and hints given by the previous or existing WSL bugs, there is probably not much the WSL driver deffer to the NT kernel, only very core stuff like virtual memory, scheduling, and on some FS code (WSL adds its own layer for VolFS). Even Socket/TCP networking needs completely custom code in at least the upper layers (not surprising when you know the completely insane architecture of Winsock, with a legacy from Win16) but probably also quite a bit in underneath layers -- result: it stills works so/so when you don't stick to ultra trivial usage of the TCP sockets. And they told that Pipe are completely custom, because the semantics is too different from NT Pipes. The Fs aspects also shows that there is probably a lack of virtualization in NT, or that for now some WSL stuffs are plugged at the wrong place. Signals are not really a concept of NT, so WSL does most of the work, and like usual in this story, it shows quickly by still having some bugs: the first trick or even mainstream but non-trivial usage you try to do, it immediately fails. Especially more so when ptracing.
In the end, what permitted to have a WSL seemingly reaching a decent state (it's still very far from perfect, but quite decent already for development purposes) so quickly is that: 1) it actually started way before any publicity about it 2) it seems to be made by a small, but not too small, very competent dedicated team working full time on it 3) Posix API and Linux syscalls have a documentation at least 2 order of magnitude better than MSDN, and a reference implementation available for everybody -- probably they don't allow WSL devs who write WSL code to look at the Linux code, but they still have access to the man pages which are more useful than the code in most cases, especially given how much detailed are lots of man pages -- compared to that MSDN doc of Win32 is a complete piece of useless crap 4) the area to cover (Linux syscalls) is smaller compared to Win32 -- Wine does not tries to reimplement an NT kernel, but the whole userspace stack -- an analogy would be MS trying to reimplement Linux + Gnome + Kde + PulseAudio + X + etc... The amount of work is not comparable at all!