What's wrong with semihosting for debugging output?

Semihosting routes the program's I/O, like printf, through the debug connection so it appears on the host's console, and it's attractive because it's trivial to enable and needs no UART or extra pins. The problem is that it's extremely slow and halts the core on every operation: each semihosting call traps to the debugger, the host services the request (which involves the debug probe and host round-trips), and only then does the target resume, so the CPU is effectively stopped for the duration of each print. That makes it disastrous for any real-time code: timing-dependent behavior is destroyed, deadlines are missed, the watchdog may fire, and the throughput is so low that even moderate logging brings the system to a crawl. It also requires the debugger to be attached and configured for semihosting, so it can't be used in the field. It's acceptable only for quick, one-off checks in non-time-critical code while debugging at a bench with a debugger connected, for example, confirming a value during early bring-up. For anything ongoing or timing-sensitive you use a non-halting transport instead: RTT (a RAM buffer the debugger reads without stopping the core) is the usual fast, minimally-intrusive choice, or UART/SWO. So semihosting trades a tiny bit of setup convenience for stopping the CPU on every byte, which is why experienced developers avoid it for real logging.