This is bearishly hard to measure. For example (this is a real, recent scenario, left intentionally vague): a new government regulation gives you 12 months to expose certain data conforming to a provided API schema. The system under development is a big ball of mud. Re-shaping the data to conform to this schema turns out to be extremely difficult but failing to produce the APIs on time will result in company-endangering penalties from a government regulator with no sense of humour.

So you put a team on the APIs and issues keep cropping up again and again because every time one thing is changed it has knock-on effects causing other company-endangering incidents because you're making changes to to way billing and invoicing data is presented, or to how incoming metering data is stored. So you put some additional teams on the project and work everyone to the bone. Some senior developers burn out and leave the organisation. Likewise some project managers. Your best QA staff have their morale drop to rock bottom.

The project delivers on time but how do you measure these costs? How are you going to put a dollar figure on the burnout and lost staff? How much of the senior developers' decisions to leave can be attributed to the project and the big ball of mud? How do you measure the impact of your best tester losing his will to work and going dark?

Many of us have worked in organisations where things have gone down like this. We all know that impact is huge. But yeah you're right, I can't put together a business case that says it in clear numbers. On paper we had a one-year project, it probably went a bit over budget but it ultimately delivered so what's the big deal about the big ball of mud? Except that our competitors were able to produce the same APIs for a fraction of the cost without burning out half their staff.

I’ve seen companies rapidly collapse because they couldn’t adapt their code base to current platforms or new requirements. As long as nothing changes and you don’t have too many bugs, your code can look like crap under the surface without issues. It’s the day you can’t sell your product without a UI that works on a phone and you have to change every single method to make the change, or you fail to implement the new tax rules correctly even after 18 months of all hands on deck, it matters.

Then it doesn’t have be that bad to have business impact. What does your customer say when the new feature that was promised in one month takes eight months to deliver, or your CFO say when it will take 15 years of licensing fees from that customer to pay those 24 man months to get the features working?

Depends on the timescale and how captive the audience is. Oracle DB has a reportedly pretty bad codebase but a captive market that keeps them from needing to address the problems (as rapidly as their customers might like). If low quality lets you be first to market, that may be worth the later maintenance costs by gaining an outsized portion of the market and earlier revenue than your competitors.

On the other hand, if you've got an old system with poor quality code and can't make changes, your customer(s) are willing to drop you, and you have competitors who can get out the desired features, you're screwed.

Nobody knows, since there is no agreed-upon way to measure code quality.

I doubt you can correlate to a line. But it may track a down-facing arc.