Good point. In some communities, certain bug work is shared between senior staff and more junior collaborators as a way to "show the codebase" to the new team members and also to foster the bug solving culture.
In my experience, this rarely happens because of developers being over-comfortable. It happens only under high levels of discomfort. Developers don't like leaving code in a bad state, but they tend to leave it if 1) the code is really messy and fixing it would be a huge effort, 2) the code-base is really fragile and fixing this bug has a high risk introducing new ones, or 3) the developers are put under a lot of pressure from management which results in them cutting corners to get stuff off their plates. Usually all three are true simultaneously.
This is only counteracted by making code quality the highest priority, and the hardest part of achieving this is having management understand it's importance. It needs to be turned into a company culture which can be assisted by numerous tools and techniques such as code reviews, automated Testing (at small, medium and large scales), automated code quality assurance (SonarQube, PMD, etc) and enforcing these rules with commit-hooks.
My experience is mostly from lower-level programming languages though, but I think these are general themes across the board.
I agree with this, most of the times I have ever said that it is not my problem is because I am restricted in time or the system is too fragile to deal with what needs to be done (often restricted by time).
If you are hitting that kinda road block a lot it is worth bring it up to more senior people to discuss what can be done around stablising the system or adding time in for bug fixes.
I have a "not my layer" attitude, bugs that belong to lower layers should not be covered on upper ones.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.