Quality is obviously a thing your team should care about, but quality is also a process problem. If an individual continually produces poor quality than the "process" should fix it via not merging their code or pip or something else.

What we are avoiding here is a CEO asking, "What caused the outage" and your manager responds "Bill wrote some code that caused a deadlock". It's possible Bill is working on fragile parts of the system, or writes most of the code. Blame at an individual level for an incident is unhelpful and, as OP points out, possibly creates a team with worse delivery incentives.

quality is not a process problem, process is generally put into place to protect against bad decisions which often also constrains good decisions (because it typically does so by constraining decisions).

avoidance of negative quality is not quality.

Let's say "done" as in God descends from the heavens and estimates every Scrum® team player's work output on a fair scale, to avoid going into meta discussions about almost unmeasurable value output.