No, I do not agree Richard.

An experienced developer is experienced about reading datasheets. And have experience looking at a problem and then try to deduce what may be wrong.

Beginners totally lack this experience. So for them, it's a huge advantage to be able to freeze the program at a specific state and compare the state in the processor with what they assumed it to be. And that obviously requires not only support for breakpoints. But also ability to look at some of the peripherial state. Some important parts of the peripherial state can be accessible using debug cells in the processor even when the state is not available to normal software. In some situations, debug cells inside the processor can allow the code to look at write-only registers.

Next thing that debug cells have the ability to not just set dumb breakpoints. But you can set breakpoints for read or write accesses to specific memory areas. So having a write-access interrupt at the end of the stack, you can switch into the debugger the first moment your program tries to overflow the stack. And the debug cells can support counted breakpoints, where you break after 1000 iterations. Single-stepping aint fun when you need to look at the result halfway through a huge initialization sequence. And beginners may not realize that without good debug cells, you will sometimes have to add special placeholder code inside the sourcecode just to help with debugging - things like:

// Dummy function to get a single place to set "multiple" breakpoints.
function dummy_call(void) {
}


for (i = 0; i < 10000; i+++) {
    ...
    if (i == 1023 || head == NULL || ...) {
        dummy_call();
    }
    ...
}

Above construct is not something people think about before they have already spent lots of time debugging programs.

Next thing is that debug cells (which takes very few transistors inside the processor, and often can make do with very few processor pins - some AVR chips make use of the /RESET pin giving zero loss of pins) allows you to debug any part of the code. From a factory-empty chip with zero software in it and all the way to a final product. What do you do if you don't have a programmer for adding that monitor? Or you don't get any serial data out from the monitor? Debug the debugging tool?

The main thing here is that transistors are basically free. They have almost zero cost. So with zero cost, it is stupid to not get a processor that adds these extra transistors in the form of intelligent debug cells. For an experienced developer, it's just a question of saving expensive time. For a beginner, it is probably the difference between a working project and a major failure.

Next thing - a debugger who are stuck and asks for help on the net, can get better help if he/she is using a processor with some ICE functionality. People can tell them what to do to try to eliminate different possible error sources.

By the way - I feel your description of your cirumvention logic incorrect. It was most definitely aimed at circumventing the licensing limitations of the tool. I.e. an unethical work-around.