Didn't you all do code reviews, project planning, etc.? These are all ways to get other devs involved and knowledgeable without explicit "you are now the owner".
Does a code review provide the necessary time for someone unfamiliar with the code base to understand all of the business logic that will be affected and where this new addition sits within that hierarchy? Code reviews have never seemed contextually rich to me.
I think the theory is that for code review to be its best, it sits on a contextual pyramid composed of reviewed design docs, pair programming, standups, and all the rest of it. That the "reviewers" are not hearing about the background, motivations, alternatives that were considered, broad implementation choices, etc etc for the first time when the PR goes up.
But often there are some or all of those pieces missing, and so yeah, code review ends up being a bit shallow and performative.
All too often, code review amounts to no more than making sure there are no grievous mistakes. Management only cares about you completing your own work, and if reviewing the work of others slows you down, that's your problem. Time spent on code reviews have never counted toward mine or anyone else's performance. A bad PR making it to production certainly gets negative attention, so that's the aspect given priority. The incentives do not align to make code review a place for knowledge transfer.
If they don’t already feel ownership, it’s easy to just approve PRs without looking at them critically. Why deal with confrontation trying to uphold code quality for a project they don’t really own? I find people don’t pay attention in reviews unless their personal success is tied to the long term success of the project.