This part is enough to mark the test as exploratory and not usable for a guide on the real world:
> The experiment was conducted on “live” projects that the teams were developing at that moment.
There are plenty of experiments on those conditions. If they had consistent results, we could trust those, but they are all over the place, what means that confounding factors are more relevant than the thing being studied.
Did the non-TDD team do regular testing, or no testing at all? It doesn't say, and it seems rather important to judge the results..
I think the debate is not whether testing in general reduces defects (which is rather obvious), but if adhering to a stringent Test-Driven Development (TDD) process is better than regular testing (typically adding the tests after writing the code, instead of before).
The usual wisdom is that the later a problem is detected, the more it costs. 15-33% extra time for removing ~half defects very early is a great trade-off!
> The experiment was conducted on “live” projects that the teams were developing at that moment.
There are plenty of experiments on those conditions. If they had consistent results, we could trust those, but they are all over the place, what means that confounding factors are more relevant than the thing being studied.