It’s possible that this code has bugs that have yet to be detected. It’s a fact that quality is important if it can generate losses. Style may not be particularly important, but reliability is.
No it doesn't. It's a variable that doesn't enter the equation at all.
Maybe the technical debt should be reduced, saving the company money down the road by reduced maintenance costs and reduced issues as development continues.
Maybe the code is feature complete and there's no reason to change what works. It has technical debt, but perhaps the business calculation is that there's not enough benefit to cleaning it up (and in fact messing with working code may introduce issues.)
Either way you look at it, how much revenue it produces doesn't enter into the calculation.
Now you might say the revenue is so low that the code brings little value to the company and so the technical debt doesn't matter. But again that's looking at the wrong thing. Even if it brings in zero revenue, as long as development is ongoing because it brings some other form of value to the company, then the technical debt matters. The right things to look at are the costs involved in cleaning up the technical debt, vs the costs of continuing on while ignoring it. It's all about weighing costs and not about revenue.
But it doesn't matter to this particular decision which is weighing one cost (technical debt) against another cost (fixing said debt.) There is no revenue in the calculation at all to consider, just costs.
It does say something. In this case, it might be saying that, for this particular application, the quality of code is simply not that important.