Technical debt is the accumulated cost of everything inside a product that makes changing it slower than it needs to be. Some of it was bought deliberately as the price of reaching a date, and some of it simply built up. The two arrive for different reasons and are managed differently.
Debt that was bought and debt that accumulated
Deliberate debt is a trade off taken with open eyes. A date mattered more than the shape of the solution, so the team built something that works and is known to be awkward. That is defensible whenever the value of arriving now exceeds the cost of the rework later, and it stays defensible only while the bargain is recorded and revisited.
Accumulated debt has no such story behind it. It is the residue of skipped tests, refactoring never done and a standard of quality that slid a little each Sprint. Nobody chose it, which is what makes it the harder of the two to manage, because no record exists of what was traded away or when the organisation agreed to carry it.
Why this is a Product Owner concern
Debt is a claim on future capacity. Each Sprint a share of the Developers' effort goes into working around what already exists rather than adding to it, and that share grows as the debt does, so a rising part of the budget goes on maintaining the product rather than extending it.
A Product Backlog the organisation is steadily less able to act on is worth less every Sprint, however carefully it is ordered, because an order is only a plan and the capacity to execute it is draining away underneath. Ability to Innovate in Evidence-Based Management names the same effect and counts technical debt among the things that push the measure down.
The decision cannot be delegated
Only the Product Owner orders the Product Backlog, so only the Product Owner can decide that work to reduce debt actually happens. The Developers can raise it, size it and refuse to add more of it by holding a strong Definition of Done, and what they cannot do is place it above a feature. Neither can a manager or an architect.
A Product Owner who calls debt a technical matter for the Developers to settle among themselves has not handed the decision to anybody but left it unmade, and the debt grows until the argument returns with a larger number attached.
How it becomes visible
The Definition of Done is the main preventative control. Work that genuinely meets it does not silently add debt, because the standard is agreed in advance and applied to everything the team calls Done. Strengthening the definition stops the problem at source.
For debt already carried the readings are indirect. The share of effort going to maintenance rather than new functionality, the trend in defects found after release and the length of the stabilisation period before anything can ship all describe one condition from different angles. None measures debt alone, and read together over several Sprints they say whether the position is improving.
What the Scrum Guide says and does not say
The Guide requires that quality does not decrease during a Sprint, and that work cannot be considered part of an Increment unless it meets the Definition of Done. Between them those rules are what stops debt being added invisibly.
What the Guide does not contain is the phrase technical debt, a practice for measuring it, or an instruction to reserve a fixed share of each Sprint for repaying it. Scrum states the constraint on quality and leaves the method to the people who know the product.
Arguing it on value rather than virtue
Paying debt down competes with features for the same capacity, because there is no separate budget for it and every hour spent on it is an hour a stakeholder wanted elsewhere. The case has to be made in the same currency as any other item. What does this buy, how much sooner do the items behind it arrive, and what does the coming year cost without it.
Put that way it is an ordering decision under uncertainty, which is work the Product Owner already does. Put as a standard the Developers are morally owed, it loses to whatever has a date attached, and the organisation ends up holding a backlog it cannot afford to deliver.