They define it in the second sentence as "trading code quality for time-to-market and new features". Section 2 defines code quality ("This section
defines the metrics for code quality"), which is helpfully (/s) measured by the tool they sell.
Quite right. Thus they implicitly equate poor quality code with technical debt. This makes the metaphor unsuited to a proper aversion to poor quality code. If it's simply debt it can be paid off later with a small amount of interest. Such a conclusion is contrary to the one the paper is trying to put forth.
Assuming that they ran the experiment in earnest, doesn't that strongly indicate that whatever code quality metrics in their product target are a pretty good signal?
(Until people target those metrics)