The design of WSL(1) makes more sense when you think of its original design goal of being a compatibility layer for Android apps. Android is "a Linux", but it is (1) a relatively unique one, and (2) everything between the Android kernel and Android apps really isolates the application layer from kernel-level details. Given this separation, it makes a lot of sense to leverage the existing NT flexibility and emulate a Linux kernel at the syscall layer. Sure, you'll have to patch some parts of the WSL(1) Android system components, but MS was already going to have to do that to work around Google-only components. In many ways, this route is no more complex than what Blackberry did to run Android apps atop their QNX-based OS.

But once you give up the specialization for Android and want WSL to be a "real Linux" (i.e. behave like a specific Ubuntu/Fedora/etc distribution) now you no longer can get away with being Linux-like, you have to be Linux (i.e. you need the syscall layer to directly mirror all kernel development and features). It's actually fairly impressive how much worked with WSL(1) given how different the internals were, but you didn't have to go that far to find tools/services/etc that just wouldn't work.

Instead, once you consider how long MS had been working on Hyper-V, and how interested they are in using it to apply additional security boundaries/isolation (e.g. VBS) within what outwardly appears to be a single Windows OS instance to the user, it makes a lot of sense to leverage that same approach to just run a real Linux kernel atop Hyper-V. In that world, you no longer have to match Linux kernel development, you just need to develop/maintain the kernel drivers used to interact with Hyper-V - and MS already had a lot of experience and need to do that given how much of Azure is running Linux VMs.