So breakpoints to debug stuff related to BLE isn't an option
That's not BLE-specific - anything that's externally time sensitive will have an issue when the related code is stopped at a breakpoint.
Now here's the thing. Let's say you have a software-controlled motor inverter or DC/DC converter. You just can't stop the program at arbitrary point, or you blow up things (semiconductors, physical things attached to motor axle, whatever).
Now you are lost trying to find some nasty bug, and the only way you seem to have is to add breakpoint in the middle of critical handler and examine internal state, for whatever reason.
The options are:
1) Add a breakpoint in debugger.
Consequence: when it is hit, all hell breaks loose.
2) Write an error handler which does safe shutdown, by doing the necessary GPIO writes to turn MOSFETs off, turn mechanical brake on, whatever is needed.
Instead of adding a BKPT, you just add call to this error handler. You achieve the same: program stops here. Difference is, it now happens safely, as defined by you.
Now you totally can use #2 to stop the system, and then attach debugger probe to continue examining the state. This is combination of manual code intervention and using the general purpose debugger.
But the thing is, once you have had to write your own handler manually anyway, why not improve it to log the state of interest? This will then break the dependency of having to rarely attach a debugger. Your workflow is simplified. This is because
you can't avoid manual instrumentation anyway, so why not make good use of it.
There is also option 3), sometimes peripherals such as motor control timers have special hardware logic so that when the debugger halts the CPU core, you can also halt the timer plus make the outputs go to some predefined IDLE state.
But quite frankly, this seems like a made-up response by the manufacturer to the criticism that breakpointing critical control code is impossible. But the problem isn't properly solved: you still only can make the particular timer module go in safe state, but likely this isn't enough, you would want to toggle a GPIO, maybe with a delay, whatever is needed for completely safe state. Can't automate everything through the peripheral. And then, finally, you need to
configure this debug mechanism in code. So you can't avoid modifying code for debugging purposes, after all.