Features over robust code
An effect is "birth defects are forever". An early design mistake is very difficult to correct in a scrum-like "agile" process. The incremental nature of the process favors patching around it.
This is OK for webcrap, but not OK for systems that have strong internal consistency or time constraints.
I have been in teams that to take the time to solve technical debt and even generate technical wealth. The best approach that has worked for me is to divide the development available time per sprint in: 33% new product features, 33% existing product maintenance, 30% Solve Technical debt (or 20% tech debt, 20% product debt with a 30-30-20-20 split).
With this I try to show that the problem of development teams NOT fixing their crap i not an issue of the Agile/SCRUM process (or any other process), it is an issue of management that prefers to ignore the mounting technical debt (until it explodes and you have the Github downtime, or LinkedIn leaks or the fact that changes become slower and slower due to codebase complexity).
I put the blame squarely on the process, whether its SCRUM or whatever.
Scrum is missing a LOT of things, because it's very specifically intended to not be highly prescriptive. The whole idea is to iterate, use empirical feedback, and evolve your process to match your context.
Right near the beginning of the Scrum Guide it reads
Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.