In addition to the good points made in the other answers, determining the relative productivity of developers is more difficult when they are not fixing their own bugs. I'm not saying it can't be done, but that it requires more rigorous tracking and analysis.
If you have every developer fixing their own bugs, the amount of (roughly equivalently sized) features that a sloppy developer can produce will be less than one who is writing code at a more optimal level of care and/or using better techniques.
That is, if a developer is trying to close out as many items as possible and bugs are distributed to the team as a whole, they can artificially increase their throughput by churning out defective code or in technical terms: 'crap'. There's an opposite issue where developers can be too worried about creating defects and become too careful. That's why it's important to focus on the throughput of working features to production and not the amount of (non-production) defects.
If you push the defects back to the developers, it creates a natural feedback loop and they can learn to optimize their productivity with limited additional information. If you don't do that, it means you need to track the defects and who created them over time and then communicate that back to the developers who are creating excessive defects. This is problematic for a few reasons but the biggest is that it may cause the developers to try to minimize defects to avoid being 'blamed' for them instead of optimizing for throughput. If this tracking isn't done, the management (lead etc.) can easily mistake their least productive developers as the most and vice-versa. The best developers will tend to become disgruntled by this situation and may quit.
The side benefit is that it's also much easier to see which developers are truly the most productive and reward/promote them accordingly. The thought of trying to track and attribute defects and then find the optimal rate seems pretty daunting and I'll assert that it probably requires some guess-work. It's also unlikely that most developers will know use that feedback to achieve the real goal (i.e.: working production features) directly.
If you have a situation where one developer is so bogged down by their bugs that they can't get out from under them, you may need to distribute those defects to other team members. However, this would be a clear indication that you have a developer who needs support and/or mentoring and (unfortunately) may not be able to perform their job adequately. Obviously, if you let someone go or they quit, the rest of the team will need to fix whatever defects they left unresolved.
NOTE: I need to make it clear that I am talking only about bugs found in during development and testing. Production defects are a failure of the team/process and attributing them to a single person is highly misguided and (somewhat paradoxically) tends to lead to more production defects. The question of how a defect got into production without detection is much more important than how it was created.
P.S. I think this is being misinterpreted. This is not about punishment. It's about feedback loops and letting developers 'manage themselves'. As an analogy, there's a condition that certain people have where they feel no pain. While initially, this might seem like a good thing, it's actually a really big problem. No one wants to suffer through the pain of being burned but these people can suffer from serious injuries where they (e.g.) place their hand on something very hot and have no idea they are getting 3rd-degree burns until they smell it or see smoke. Having your defects come back to you is like that immediate pain feedback most people have. You learn of the error you made much closer to when you made it. This allows you to correct and learn much more efficiently.
