One of the suspected main reasons why we don't have proper original Xbox emulation yet on the PC is because of the fallacy that "it should be easy to emulate an x86 console on x86 PCs". This has lead to many failed attempts to attempt "shortcuts" of running Xbox games on PCs, like converting executables statically, or extremely high-level emulation approaches like only emulating graphics calls. None turned out not to be so easy in practice. The notion "it should be easy to emulate architecture X on architecture X" does not tend to hold up very well, at least not for game consoles that also have complicated graphics and sound.
Compare this to Dolphin, which has been wildly successful in emulating the Nintendo GameCube. Besides the big popularity of Nintendo games, the GameCube was comparable in complexity and sales figures to the OG Xbox. But since it had a relatively non-standard CPU architecture and a non-standard GPU setup, it guided emulation developers to not put too much effort in shortcuts and tackle the emulation problem head on.
It's worth noting some recent progress has been made in OG Xbox emulation by the Xqemu and Cxbx-reloaded projects. The former tries to use qemu for x86 emulation (or even virtualization?) while "low level" emulating the rest of the Xbox hardware, whereas the latter started life as an extreme high level emulator that is going more and more low level over time.
I think almost all the interesting games on the X-Box either already being available for Windows or else having a just-as-good version available for another console is a lot of what kills interest for emulating it. You can play Halo and such just fine on a PC without an emulator.
Usually, no. Emulation generally goes through a JIT that couldn't really care less; there are some processor features that can be difficult to emulate sometimes but often even on a similar ISA you cannot just "use your processor directly".
Now if you're talking about trying to run one of these emulators on an ARM build of Linux, you wouldn't see these performance improvements since their designs are optimized around x86 CPUs, not ARM.
Edit: Several far more informed comments than mine have mentioned that running on ARM is only one small piece of the performance coming from DraStic.
The fact that its performant is tangential to the fact that its running on ARM android. IIRC Drastic still does a traditional JIT to recompile the guest ARM code into ARMv7a for phones (I might be misremembering, but I recall they had a whole lotta headache trying to update to support 64 bit ARM in time for the Android deadline for that. Also I remember them talking about tons of headaches dealing with the new storage APIs for Android)
Its really fast because of the tons of optimization that went into the application. It does many cool things to cut out overhead on the CPU side, but also it does a lot on the graphics emulation side, including hand rolled ARM NEON code for SIMD processing polygons. I'm not very familiar with DS emulation, but one of the devs for Drastic contributed to another project I worked on, so I had some chats here and there about these sort of things.
The DraStic developers have commented that they don't gain much if anything because it runs on ARM [1]. It's just an efficient emulator. If/when it is open sourced as promised, it will run very fast on x86 systems too most likely.
In any case, DraStic is a completely different style of emulator compared to Yuzu. The Nintendo DS is nothing more than a pair of microcontrollers with (from a modern perspective) primitive 2D+3D acceleration hardware, whereas the Nintendo Switch is a multiprocessor system with a modern GPU and mulitasking operating system. The DS CPUs are actually quite far removed from modern smartphone chips, whereas the Switch chip should be mostly standard ARMv8. Things that apply to one don't necessarily apply to the other.
