In the case of the Switch, it's not necessary to emulate the whole device or even processor, especially if the intention is to run Switch games on a computer. Rather, high level emulation is more than sufficient — anticipate what the software depends on the actual hardware to do and redirect it to do the same using what the computer has available.
Switch has an ARM processor so it's definitely a requirement to emulate that, which QEMU is well-suited for. But to your point, Windows has great graphics APIs that would make it easier to pipe the graphic stack from the Switch OS into rather than writing your own implementation. The processor can be taken care of via JIT as well, but it still needs to be lifted.
It's in its infant stages at the moment according to the "Emulation General" wiki and focuses heavily on "accuracy" over performance
Other emulators such as CXBX-Reloaded have made larger strides, currently emulating roughly 10% of the software library
It's also worth stating, while the Xbox seems like an "easy" target, being based on an ia-32 (Pentium III) PC with an Nvidia GeForce chip (somewhere between a Geforce 2 and 3 at the time) it is an absolutely monstrous beast with minimal documentation about its hardware and numerous "gotchas"
It also has a very small library of 'exclusive' content which detracts from gaining many developers
I mena, in principle, presumably.
> that QEMU already does
Potentially a couple devices. But for most of the hardware, probably not.
Regardless they might—I would—find QEMU harder to hack on, harder to extend, because it is written in C. C is of course the lowest level of all high level languages.