On intrusive systems, typically one or more of the following resources are consumed: a certain amount of code space is used for emulation, an interrupt is lost, several internal RAM locations are used (e.g. stack), port pins are used, the memory interface may have constraints on its use, code is manipulated to support software breakpoints, and so on. This often lacks proper documentation.
Even simpler systems also consume the UART and a timer. These simple 'emulators' cannot provide trace and other advanced debugging functions, while also being very intrusive in the debugging cycle. Imagine trying to debug an interrupt problem while the 'emulator' itself is manipulating interrupts!

Unfortunately the term 'emulator' is not protected. Therefore lots of manufacturers of debug tools call their device an 'emulator', although it might be a comfortable but intrusive monitor.

Developing firmware is all about producing code that is 100% reliable in operation and fully understood in how it will perform in adverse conditions. A real emulator that assists you in this task is the most important tool you can have.