There hasn't been a lot of great quantitative scientific study on how to productively do science either. Academic science is a craft, and is more or less learned through apprenticeships.
I'm trained as a physicist, and I'm certainly a fan of quantitative scientific methods, but I think it's important to realize that there are some areas where quantitative science is effective and rewards the required work well, and other areas where it is largely an ineffective waste of time.
I suspect trying to quantitatively study things like "how much unit tests really affects the bug density" is one of these cases with a poor reward to effort ratio.
There's a danger in trying to apply quantitative science to complex phenomena, when many or most relevant factors are actually uncontrolled and unmeasured. Once you have a number--any number--the tendency is to fetishize it at the expense of broader thinking. Make no mistake: quantitative measurements of the behavior of people performing complicated tasks do not carry the same epistemological force as quantitative measurements of the magnetic dipole moment of the electron.
Scientists themselves more typically try to understand their own craft through case studies and "professional wisdom" passed down from practicing experts to apprentices. Software developers would probably do well to (continue to) do the same.
Can you reference those claims? If I ever repeat this claim, I would prefer to be able to link to the administrators' statements directly.
There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers.
It would require a major effort to first study the existing emergent software craftsmanship practices to find common patterns and to scientifically evaluate their effectiveness, and the results would have to be taught in the hypothetical future curriculum where future software engineers would be made. Then we might have software engineering instead of just software craftsmanship.
It's almost a bit amazing that software "engineers" who can be very obsessive about getting the data or A/B-testing will craft software based on methods they have no data about.