It lightly translates binary formats (Windows executables) into Linux-compatible executable code, and then runs that code against libraries that implement Windows APIs in terms of Linux underneath. It's not an emulator in the same way that your libc isn't emulating lockf(3) in terms of fcntl(2) underneath. In web-dev parlance, we'd call WINE a polyfill.
Rosetta and QEMU on the other hand are emulators--emulators, in this instance, being a term of art that implies interpreting bespoke meaning from machine code instructions written in another program. Some emulators translate instructions 1:1, some have optimized stencils, some (like Rosetta) have kernel support for emulating very quickly, and some (maybe like Rosetta; sources disagree) also have hardware support as well.
It "emulates a behaviour" and natural language is fluid, so sure, you could call WINE an emulator and I wouldn't be mad at you. But WINE is very different compared to what most emulators are. Usually the term is reserved for when you emulate in software what used to be hardware.
"SUD" Syscall User Dispatch feature in Linux 5.11 +
Does this not involve transpilation? I guess I was grouping that in under dynamic recompilation and AOT techniques.
Regardless, I don't think that there's a benefit from defining emulation from an implementation rather than an empirical perspective. If it runs a chunk of code as if it were in a different environment, I'm kind of ok to call it an emulator. To the sibling's point, a polyfill would also fit as an emulation layer here.