What does "(not) emulating hardware other than the CPU" mean?
This means that whenever the software being emulated accesses hardware, it won't work in Unicorn in the same way as on actual hardware.
We have several questions about emulating firmware on QEMU. The general answer is that, when you try booting a firmware kernel in QEMU, that kernel will access some I/O ports, but in the emulated environment, those I/O ports won't react in the way they should. For example, an input bit that signals "device ready" will be stuck in one state, instead of toggling between true and false.
To make your software work as intended, you need to emulate this hardware as well - for example, your emulator needs to know something like:
Bit 3 of the input port at 0x124 is the "ready" bit, when it's set to 1, there's one byte of serial input waiting at port 0x125. Reading port 0x125 will reset the ready bit to 0, and it will stay in state 0 until the next byte arrives on the serial line.
And if you want to emulate how a software reacts on some particular input on the serial interface, you'll have to build on that specification and make the emulator provide your input at these I/O ports.
But of course, you need information about the hardware first, so this isn't very useful to reverse engineering. It may be useful to the hardware designer though to find some bugs that are difficult to reproduce or monitor on actual hardware.
As a specific example, consider the A20 gate on 16/32 bit PCs. Indeed, the same instructions:
mov ax,0ffffh
mov es,ax
mov ax,es:[01234h]
May access different memory depending on some bits you wrote to the keyboard controller. You can't get this right in an emulator unless you emulate hardware as well.
When is QEMU more useful?
Mostly for not RE-related tasks.
If you want to emulate an old MS DOS program, you'd need QEMU, just because those programs did so much hardware manipulation themselves as the OS lacked the APIs. (Of course, in this case DOSBox would probably be more suited than QEMU).
Or, if you want to make an emulator for a Gameboy, C64, or just any other kind of vintage hardware, you need to simulate the hardware as well, so you'd need these QEMU features.
When is Unicorn more useful?
For RE tasks, you typically don't need hardware emulation, because you don't have access to hardware design documents anyway. So, an emulator that omits these parts of QEMU, and improves other parts, is probably more suited to RE than QEMU is. Especially the "does not need an environment" part can make stuff easier.
As a concrete example, take one of those "do my homework for me" questions - this, and this. When you have an assumption what a function does, you may want to run it to check if some specific input produces the output you assume. With QEMU, you need to compile this to an ELF file, and set up an operating system to run your program; with Unicorn, it seems like you can run the snippet directly (of course you still have to assemble it, and need to initialize registers in a sensible way, but you don't need all the rest of the bloat).
Or, another example, you have a program that deals with DRM protected data, and includes some functions to decrypt the DRM. If that program runs on ARM Android or I/OS, and you want to have your PC do the decryption, you can try loading the program into memory and tell your emulator "start emulating at address 0x12345678". It seems to be much easier to do this if you don't have to provide all the environment, and dependencies, that QEMU requires.
