I would argue that the stronger reason is that Windows typically doesn’t enforce, allow, or contains any distinction between kernel code and user-space code. This happens because there is a gigantic gravity well of pre-existing code that predates and/or precludes real separation, and the costs of concretely losing that support was nearly always judged higher than the abstract benefit of adding separation.

One old example: I have an old friend who used to do sysadmin work in the Windows 2k days, and he would often get gigs by speeding up services by 5-15% within a day. His go-to trick was to log into the headless win2k server and disable the screensaver process, then wait.

Windows NT (and as a result win2k, xp, 7, 8, and 10) has always had strict user and kernel space separation. Modern Windows also has separate 'integrity levels' within user space - for example, Chrome and Firefox run most of their functionality at 'Low' integrity to prevent compromised browser code from being used to exploit other processes. I'm not sure what the basis is for the claims you're making about the kernel. The idea that distinguishing between kernel and user code is Not Allowed is very confusing to me, how would you do that without running both user and kernel code at the same privilege level in a shared address space?

The CVE here literally has nothing to do with privilege separation or being unable to distinguish between user mode and kernel mode. It's this simple:

* Someone in user-space wanted to parse an executable to get information on it

* A syscall is exposed to parse an executable

* They used the syscall to parse the executable, and that code path had a bug in it which triggered a BSOD (since the failure was in kernel mode).

In the end, this is just "a syscall had a bug in it that caused a kernel crash, and a user-mode application issued the syscall on mouse-over".