TSO is just one part of Rosetta. Another significant performance win is that it’s sloppy with keeping the runtime out of the emulated address space to save on a (slow) software MMU, which may not be feasible for other implementations.
This is less a security thing and more an emulation fidelity thing. A “true” emulator will make itself invisible from the running program so that it runs as if it was on the real system, but a Rosetta program can do things like modify the emulator or control flow in ways that are not possible on a real system because the runtime is mapped into the same address space without protection. For most Mac software this is not a problem because they will not try to access wild memory or enforce mappings, but on other platforms I can see this being infeasible (on Linux I can imagine programs that get upset if they can’t control the full address space outside of what the kernel reserves, for example).
It's extremely standard for user space only emulators to not attempt to hide themselves from the emulated code. Every implementation I can think of that derives from HP Dynamo ideas doesn't attempt to since fundamentally you need to have the translated code cache mapped anyway to be able to execute it. You're never going to be able to hide yourself completely wiht any useful perf without transmeta like special mmu hardware that has completely separate translations for I and D fetches.
You can see how the build directories for qemu are {architecture}-softmmu for the full system emulators, and {architecture}-linux-user for the user mode emulators for another example of this but with Linux binary emulation.
