I've actually asked myself this question.
The accepted answer makes some reasonable statements, especially regarding the systems and acronyms mentioned by the OP. For sure, true multithreaded emulators don't give us much at the emulation level.
However, I've been looking at getting truer emulation of a KIM-1 board, with more complete RRIOT emulation, with usable maskable and non-maskable interrupts for the purpose of timers (i.e., timers that can be scaled, restarted, and accessed by the programmer).
One approach there is an implementation of multitasking in the emulator (which doesn't have to actually be truly parallel) so we have independent timers (or a single timer) that can be scaled, hooked up to "interrupts", etc. That is, user code could run that checks memory locations for timer info that is supposed to be ticking over even as our own program statements are being stepped through. More importantly, it might be a good way to emulate interrupts that a program subscribes to, allowing our own interrupt handlers to work as expected.
The intention is to emulate more closely the machinery of the CPU and support chips so that the registers, programmable interrupts, and read-only memory locations that change as the hardware ticks behave more as expected. But doing it without coding it at the tricky per opcode load-and-execute level.
I think it might be easier to emulate the target CPU speed a little closer, too, or at least get timer resolution pretty accurate. That is, what happens between the various timer location updates and interrupts is not that important as long as those ticks and interrupts are correct when user and ROM routines access them.
Yeah, still a work in progress.