That’s what I guessed from the article, especially when I read that it only works with breakpoints but in this case is there a reason to not call this "debug mode" ? Because it sounds confusing.
Or maybe there are other usages than just debugging ?
"Semihosting" is a very old term for this ABI (it dates back to at least the late 1990s in a bit of Arm documentation I found, and might well be earlier). It's mostly I think a name coined when looking at it from the point of view of "what is the C library this guest program linked with using to do stuff":
* hosted == we're running on a real OS, and printf etc become system calls to that OS
* freestanding == this is a bare metal program (perhaps it is itself an OS kernel) and much of the C library facilities are simply unavailable
* semihosted == an in-between position, similar to freestanding but with printf and some other facilities talking over a debug protocol to a connected development system, so you get more of the conveniences of a hosted C library during the development process
(the first two are C standard terminology.)
The use of the bkpt insn is also fairly new, being specific to M-profile (which is the device the blog post author happens to be using). The original 32-bit Arm version uses SVC (the system call instruction). Either way, use of the instruction is caught (by a debug ROM on the guest, or by a JTAG debugger, or by an emulator/software model) to perform the necessary operations, in a flow that is separate from use of bkpt as a true breakpoint).
More recently some other architectures have borrowed the "semihosting" term to refer to the equivalent ABI they provide.
It is basically a debugging feature: giving you printf support through the JTAG connection instead of needing a dedicated UART or something like that. You can also do some stuff like read/write files on the host as well, but again this is basically only useful for debugging.
Or maybe there are other usages than just debugging ?