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.
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 says everything it needs to say. Revenue pays developer salaries.
A developer took the time to review the existing code, and point out things that could be improved upon. That's part of our job. Even if you don't want to make any changes, or he's wrong about some of the feedback, you should be grateful to him/her.
How much revenue your code is earning says nothing about the quality of the code. That you feel the need to mention it says something about your ego.