To me it depends on the dynamics of your team.
For example, if you have a team which isn't unified by standards, peer review, methodical testing, or if you have a team where the competence levels vary wildly among the members, it might be good to seek a stronger notion of code ownership with a more black-box modular mindset.
Lacking this, for example, your carefully-designed interface conforming to SOLID principles might quickly be ruined by someone who doesn't even know "SOLID" means and wants to add new eclectic functions all the time to the interface for "convenience", e.g. This is, by far, the worst.
You might also deal with sloppy co-workers whose idea of fixing a bug is fixing the symptom without understanding the root problem (ex: trying to respond to a crash report by simply putting workarounds in the code only to hide the bug and transfer the deadly side effects to someone else). In that case, it's not quite as bad as interface design sabotage and you can protect your intentions with carefully-constructed unit tests.
The ideal solution is to tighten up your team though to a point where this notion of authorship and ownership no longer become so important. Peer reviewing isn't just about improving code quality, it's also about improving teamwork. Standards aren't just about consistency, they improve teamwork.
Yet there are scenarios where peer review and actually having everyone conform to a standard is just hopeless and will bring a lot of hopelessly-inexperienced critics into the mix. I'd say a lot of whether code ownership or team ownership takes a stronger priority will be based on your team's ability to actually perform an effective peer review and actually leave everyone coming out like they benefited from it (both in terms of the review itself, and becoming closer together in mindset and standards as a result). In large, loose, and/or disparate teams, this might seem hopeless. If your team can function like a "squad" where you can barely even tell who wrote what, then sole ownership will start to seem like a silly notion.
In these kinds of far-from-ideal scenarios, this notion of code ownership may actually help. It's trying to make good of a worst-case scenario, but it can help if teamwork is generally hopeless to put a fence around an author's code. In that case, it's diminishing teamwork but that can be better if "teamwork" only leads to toe-stepping.