If you think about wine and dxvk, it's pretty much the same concept, without the need to emulate a CPU.
On the contrary, Higan uses low level emulation(LLE), wherein the actual hardware of the system is emulated as faithfully as possible, which is very CPU intensive.
But yeah, the progress reports are now mostly fixes for very low level stuff like emulating a specific hardware cache just right or matching the /exact/ semantics of AMR64 floating point for certain titles.
[1]:https://wiki.dolphin-emu.org/index.php?title=Wii_Menu#Keyboa...
This means that less accurate emulation can still result in a playable game, whereas missing the timing of how the SNES CPU moved data to the PPU could render scanline-specific register twiddling used on actual hardware into gobbledygook.
But even still, higan/bsnes were notoriously CPU heavy because it took a different approach to emulation (perfect low-level emulation of the actual hardware system). Even with SNES, if you were willing to relax perfection you could get very playable games with much less CPU usage, as shown by emulators of the 90s.
In fact that was my own intro to emulation, zSNES playing SNES FF6 on Pentium-class hardware. The Switch has evolved a lot since the SNES, but so too have desktop computers.
Those also have some significant tradeoffs between emulation accuracy and speed, though because they were focused on playable games at speed, not necessarily perfect accuracy.
The later emulators have tried to do low level emulation to get accurate cycle counts and whatnot to make it as close as possible to a real SNES.
Might be wrong about this but I believe SNES emulators are now approaching "perfect" emulation which is to exactly emulate the hardware down to every defect. This is what can slow things down but will give you perfect reproduction of games. A lot of modern emulators use hacks (sometimes game specific) to achieve the performance you see but can result in experiences not like the game on a native console.
All that being said though, the teams working on these emulators really matters in terms of the performance they're gonna eek out of modern day computers.
In some cases games would even rely on facts what happened after each cycle of a 3 cycle CPU instruction.
Fortunately for emulator writers, that's not possible on modern hardware. They operate much more like a series of independent boxes, and you can't do such exact cycle counting. That means you can do things like rewrite ARM into x86 and just run the CPU, and only need an approximate count of how many cycles it has done.
It's much more like an interrupt driven PC architecture where things just...happen, instead of hard polling, ta, say, every vblank or the end of every scanline.
This is also why they can run at different resolutions, even different aspect ratios. (For instance, most N64 games will quite happily run at 16:9 1080p/60 fps. There might, depending on the instructions used, be some distortion on things like menus, but overall it works surprisingly well.
Interfacing with the graphics hardware is often “translated” to more conventional DirectX/OpenGL APIs.
[1] https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-rep...
Additionally, modern console might use the same hardware as PCs themselves (I don’t know how close they are), so let’s say if a console is using x86 already on a linux-based machine, then your job to write emulator would be to only implement whatever missing on the os, passing through everything else to be ran natively
Purpose built hardware can do many operations in a single or fewer clocks. For example reading an input, doing some math to it, and outputting it. A modern microcontroller can do some of that pretty fast, but change over to something like a PC and you're actually fighting a lot of delays in processing. For example you cant just thread out the various hardware components and emulate them efficiently. The OS is going to schedule when those threads execute. Therefore you get locked into one core and are dependent on single clock speed. Even then you're fighting inefficiencies in emulating real hardware.
It's relatively easy to get the first 90%, but each 1% after that doubles the difficulty. This is especially true on older machines where the code tended to be hand-written assembly. When working with modernish machines where there's a SDK for C/C++, high level emulation tends to be much easier to accomplish-- and this is why there wasn't anything even remotely resembling accurate for N64 until the last few years. It was only feasible recently.
Gamecube, Wii, Switch, X360, PS3, PS4 -- these are machines that will remain HLE for a long time. Cycle accuracy will be arduous and require CPU resources we likely won't have for a long while.
Modern machine emulators (outside of hypervisor based virtualization) don't use cycle-accurate emulation. Instead they use high level techniques such as intercepting 3d draw routines and translating them into OpenGL/DirectX/Vulkan API calls. In addition, they take heavy advantage of JIT to compile the code to more close to baremetal instructions for the target architecture, which isn't viable for cycle accuracy.
One of the main reasons older machines require LLE is that they're cycle intolerant and rely on specific timing for many effects (although, you can still get 90% there with most, just being "close enough"). Newer machines (from the PSX on, for the most part) use pipelined architectures and are strongly interrupt based, so timing is generally less important.
Tl;Dr - No matter the case, cycle-accurate is the ideal case. But newer machines are just more tolerant to bad timing than older machines.