In informal surveys, I find that most corporate programming teams with a "live" product spend (pre-consult) 60-80% of their time dealing with defects.

Bear with me here...

Let's use the lesser case of 60%.
Let's assume we're measuring in 10-work-day periods.
We are productive in new work around 4 days-worth/week.
Probably not in a row.

In this case, a sum of about 6 days of effort out of 10 is spent on defects/bugs/failure/fixes. That's just simple factions so far.

Let's say that to create zero new bugs, the team had to spend twice as long programming.

That's 8 days of programming, 0 days bugs.
We're done in 80% of the sprint.
We can do 20% MORE WORK.

We would spend TWICE as long, and be able to do MORE work? That doesn't sound right!
But yep, 8 days of work, zero bugs, 80% of the week is getting the normal work done. 2 days (20% of the week) is available for doing more work.

But let's go further. The 60% time that goes to bugs? Those are probably fixes to code which hasn't gone live yet.

Last period, there were defects of one form or another. We are fixing them this period. So avg around 10 days delay going live with that code.

What was done quickly in 4 days has come back to haunt us 10 days later (sometime in the next period, avg around 10 days is reasonable). It has compressed the time available for doing new work, either delaying the new work or causing it to be rushed.

Any faults in the rushed work done quickly comes back later.
Including rushing fixes to the prior faults.
If it is only one or two sprints, we can see our results are taking 20 or 30 days to go to production.
If we had no defects, they'd go live on the day of completion.

If we are spending 80% of our time on defects, then tripling the time gets code out the door sooner and into the hands of customers.

If you're working on defects in unreleased code from prior sprints, then the best thing you can do to speed up is...

... I know this sounds daft ...

slow down and use more care, more collaboration, more testing, more pair- or mob- or swarm-programming. Whatever reduces defects.

And ESPECIALLY close down the kinds of defects and problems that cause any kind of down-stream returns. PRs? QA cycles? Automated tests? Quality scans? Security scans?

REDUCE ROUND TRIPS.
REDUCE DELAYS FROM HANDOFFS.
SPEND ON QUALITY FIRST.

I know that it sounds natural that if you're running behind and don't get much time, you should push/rush/hurry/cram.

But does that really work?
All my experience and informal studies say "no."
And all I've read about quality says "no."
Common sense is wrong here.