That's assuming that you have a functional ICE[1] and aren't dealing with a timing issue in another subsystem :).
ICE pins are usually configured with the exact registers this article talks about. It's common for UART/SPI serial port configuration to be a part of enabling ICE. Some chips also let you disable the ICE pins so that you can use them to pick the cheapest chip possible.
Because ICEs are overrated. Many systems can't be debugged by single stepping (think servos or anything with physical hardware being controlled). ICEs rarely work well—every single one I've ever used was completely unreliable and required lots of fiddling to make it work. And then the next day you had to start the whole fiddling process over again. In the end they aren't very productive except for very specific types of bugs (they are invaluable in the very beginning of a project when you are bringing up a board). Once everything is generally up and running I find them to be pretty useless.
Yeah if you can get that to work. It's usually a serious hassle.
Another issue is that with microcontrollers you are usually debugging really low level stuff like interrupts where you can't even do printf debugging. Or you are setting registers on some black box subsystem and it just won't work and the only way to fix it is just keep randomly changing registers until you find the one you got wrong, or if you're lucky find working example code and bisect from that.
Or you've got some timing sensitive code that you can't stop and the only debugging channel that is fast enough is toggling group connected to an oscilloscope.
ICE pins are usually configured with the exact registers this article talks about. It's common for UART/SPI serial port configuration to be a part of enabling ICE. Some chips also let you disable the ICE pins so that you can use them to pick the cheapest chip possible.
[1] https://en.wikipedia.org/wiki/In-circuit_emulation