I do not understand what you mean by my being right. I did not say that. As you wrote it, it's a trivially true statement, and I didn't think what I wrote was so trite.
I will try to reword it. In the "Red - Green - Refactor" style of TDD you are allowed to refactor the code so long as the tests remain green. This assumes there are sufficient tests to catch errors in the refactoring. However, one of the allowed refactorings is "Substitute Algorithm"[0]. The new algorithm may have have corner cases which the old algorithm did not have, and so wasn't originally tested.
R-G-R omits the part where you add new unit tests which are expected to be green, but added in order to verify that the new algorithm really does work correctly for new corner cases. It should be "Red-Green-Refactor-Yellow-Green", where "Yellow" means "do the failure analysis to ensure that the refactoring didn't add new failure cases." Yet TDD people don't teach that.
And I think the reason why is that this "Yellow" stage is the normal part of non-TDD programming. If you drop "Red-Green" and just iterate over "Code-Green-Yellow-Green" (write the code, make sure the old tests work, do the failure analysis, and make the new tests work), you'll still end up with good quality code.
This comes back to another aspect of TDD. Suppose that the programmers in a company are in their 20s and 30s while middle management is in their 50s. There is an asymmetry as middle management has much more experience in applying pressure than the younger programmers. Managers, after all, have more experience trying to manipulate people.
Some programmers in this situation use TDD as a tactic to resist external pressure to release code with insufficient testing. "The code's done, but it isn't fully tested." "It's done? Ship it, and we'll deal with the problems later." With TDD this becomes "we're using TDD because <famous people> say it's a best industry practice". This gives the programmers a way to externalize the resistance to releasing poorly tested software.
However, it's also unprofessional. Some code can be lightly tested, perhaps manually tested instead of a unit test suite. TDD shuts off the dialog about how to make those trade-offs at the business level, in the name of either technical purity or an unwillingness or inability to really negotiate.
"if you follow the TDD process, all your code comes up as covered by a code coverage tool"
No, that is incorrect. I have given two examples of how TDD code can end up with less than 100% statement coverage, much less 100% branch coverage.
Ken Beck wrote "TDD followed religiously should result in 100% statement coverage." You backed that off a little with "should be near 100%". But my point is that these are assertions of faith, which TDD proponents repeat without evidence.
If they repeat this without evidence, what else are they repeating without evidence?
I myself have written non-TDD code, then tests, then verified code coverage, and ended with 98% coverage. (I wasn't able to test malloc() failures, though I coded in handlers for them and manually exercised those code paths to make sure they worked.)
[0] As Fowler originally described it, "Substitute Algorithm" is used "to replace an algorithm with one that is clearer." However, if a new test appears to hang, and analysis shows it will take several days to finish, then you may need to use a more complex algorithm with better scaling performance. If this isn't a refactoring, then what is it? Others, like https://refactoring.guru/substitute-algorithm , don't require that the new algorithm be simpler.