#9 might be a symptom of a structural problem. If developers routinely encounter problems arising from technical debt, and are continually asked to fix those problems, but are somehow never afforded the opportunity to retire the technical debt, that creates an aversion to the maintenance work.
"If it ain't broke, don't fix it; if it is broke, just use duct tape."
A lot of places have infinite budget for fixing things an a patchwork fashion, yet zero budget for planning ahead for the maintenance phase, or for scheduling preventative maintenance. It's the equivalent of never going to the doctor for a checkup, and only going to the Emergency Department at the nearest hospital when an organ explodes. Nobody wants to be in a long-term relationship with an exploding-organ person, and it's the same for code.
---
#10 is an organizational issue. If a dev has "ownership" of a particular domain, they will naturally work very hard in the short run at setting it up so that they may be as lazy as possible in the long run. But if they are continually kicked off their catbird seat of smoothly-running machinery in order to clean up other people's messes, then there is some incentive to exaggerate the effort it takes to clean up their own mess. Or to make it appear as though they have a mess to clean up.
Even worse, if no one has ownership over anything, there is incentive to always drag heels on the current thankless and tedious task just to delay assignment of the next thankless and tedious task. Do the minimum amount of work to fix the current issue, and let the next guy deal with the fallout, even if the next guy is also you. Because if you bust your ass to fix it right, the next guy won't thank you, because there is no next guy. You can only work on the stuff that is broken, and if there's not enough work to do, people get laid off.
And that is the equivalent of under-staffing the POS cashiers, so that none of them are ever idle. That strategy results in fewer customer transactions, because when cashiers are never idle, that also means that there is always a wait for customers to check out, no matter what size the order, and the cashiers have zero individual incentive to complete an order quickly. Monitoring scan rates only covers the problem, which is that employees are implicitly punished for doing their job too well. Go to Wal-Mart, and all the cashiers are always busy, but also always dragging ass, and all the check-out lines are three customers deep. Go to Publix, and cashiers with empty lanes cheerfully offer to check you out the instant you have found everything you need, and will direct you to the correct aisle if you haven't. Idleness is not just doing nothing, but is also customer responsiveness.
When other devs do this, your best tactic is probably just to follow their lead, and possibly collude with each another against management for your own benefit. The org is broken, and you won't be allowed to fix it.