Dev experience is usually at worst the same as Linux when you use wsl as you don't really need more than the terminal
For wsl, it's just a normal VM that's integrated with Windows. Maybe it'd get in the way of I did development that needed to work closer with the hardware, but I don't at the time
You can still choose most things, but they will keep asking and twist your arm as much as possible.
I have a semi-complex app I've decided to port to Windows (it's so far on Linux and MacOS and configures/debugs/tests servo motors on serial and CAN busses), and after a couple of days I've been unable to make any sane workflow work without installing three seperate half-assed copies of Linux userspace (Git for Windows w/ its bash install, cygwin and wsl2) and choco on top to install more Linux/Unix-originated stuff. It's a lot like MacOS and needing to fiddle with homebrew, except worse and you need four of them.
Let me give you an example: I have a serial device connected to an SBC mini computer that I want to interface with from my dev PC, so I want to proxy that serial port over tcp to Windows and make it available as a COM port. On Linux this is trivial to do using socat, or ser2net+socat.
On Windows, plenty of similar tools exist. Usually you need two of them, one to make a virtual pair of COM ports, and another one to pipe a TCP socket connection into one end of the pair. So far, so good.
Except all of the utilities, drivers, etc. I've tried have just plain not worked, and I've tried a good half dozen. Often their last version is from somewhere in the 2007-2012 time frame, and something no longer works on Windows 11. I think a lot of devs of tools like this just nope'd out when Microsoft started enforcing signing and pushed the Store model harder, and moved to Linux or Mac.
In the end I had to write my own thing for the COM pair and run socat in cygwin.
And I've jumped through a few hoops like this.
I'm sure if all you do is need a place to run npm from and the rest of your stuff is all in the browser, the OS barely matters. But for native dev, Windows feels dead and barren, and fully reliant on the Linux ecosystem to be productive at this point. It's where all the reliable and well-maintained stuff comes from, whereas Windows-native tools are a ghost town of abandoned, frequently closed-source binaries.
The many years Windows couldn't make their minds up between the managed code .NET stack and native C/C++ APIs, and one was incomplete while the other bitrotted away, have really taken their toll, I think.
Unix-likes are far more productive environments for what I do.
From what I remember only the c/++ toolchains were a problem on windows but the couple of times I needed them they were either managed by some other build process and ran fine or I could just compile and run in wsl