Nice points here.
I'll have to do a show on "spike and stabilize." This strategy of "late" refactoring and micro testing is something we are forced to do when encountering untested legacy code. So this as part of the "tool kit" to be a master and difficult for someone who is proficient.
My perception is that Spike and Stabilize, always takes longer than TDD because:
1) I have to spend time "re-discovering" what the code is supposed to do in order to write the test.
2) If I need to use the debugger or print statements to learn what the code is doing,
these temporary diagnostics aren't automatable and the value achieved
can't be checked into source code.
3) I have to work harder at bad design decisions that occur when not thinking about unit testing.
4) I find APIs aren't as intuitively crafted because TDD forces you to define your interface
to get started (a simple version which evolves as needed) rather than
the steps of: "write code, get it working, go back and refactor and test"
5) The costs increase with Spike and Stabilize with the time delta between
the moment the code is written to the moment tests are added.
6) Plus Spike and Stabilizes allows people to be pressured into doing the
wrong thing: ship it now, worry about test automation later.
If you're disciplined, this won't matter because you can simply say no.
If you're not, test debt increases. TDD removes this possible risk.
Thank you for the name, "spike and stabilize." It sounds better than "Test Later Strategy" but I fear it obscures the risky and uncertain future.