Many of these reasons are the same: inability to pivot and adapt to adverse circumstances. For example, you cited "they had to build on top of pre-existing shit and couldn't do it right" as a creator of bad programmers. You sound like a college student on this one, because this is the norm in the software industry. Every programmer (good and bad) has faced this one
several times. The difference between bad and good programmers is that good programmers make the extra effort to learn the lessons that no one will explicitly teach them (i.e. figure out why the "pre-existing shit" got all fucked up in the first place) whereas bad programmers just accept it as-is or, worse yet, learn the wrong lessons and conclude that the pre-existing shit is how it should be (i.e. people who believe that C++ or Common Lisp, warts and all, are infallible languages, immune to reproach or change).
Having mentors, supportive management, and interesting work is great. But these are not the norm anywhere and they're certainly uncommon in the first few years in the software industry. A career average of 25% on these, for one's first 10 years, is probably about par. The good programmers are those who figured out how to get better in spite of these setbacks.
If I were going to put it into simple terms, the problem with the worst of the bad programmers (the deserving underclass) is that they don't expect much of themselves. They're happy to chug along at 100 lines/month on uninspiring work, and they do just enough not to get fired, but they don't achieve enough to offset the complexity load they create by modifying code while not knowing what they're doing, and by imposing resistance-to-change on the organization they inhabit. That's Class #1 of bad programmers, the ones who've been powerless for too long and are now just passing through. It probably comprises 65% of bad programmers out there.
Class #2 is the do-the-wrong-thing-well type. These are the ones who are generally very intelligent but narrow-minded. For example, they optimize for runtime performance at the expense of code readability, or who use the wrong languages, or who eschew databases because "SQL is a mess; let's just use the filesystem". They tend to be really, really good at some small subset of programming and tend to want to use that set of tools and skills even when not appropriate. These are the people who annotate an O(n^2) sorting algorithm as "WRONG!!" even when it's sorting a collection of 20 elements, because to them, not optimized == wrong. Their learning rates were too high, and now they're stuck at suboptimal local maxima. That's 15% of bad programmers.
Class #3 of bad programmer (15%) is the rock star, the kind who writes lots of code quickly, uses fancy "metaprogramming" features, but no one can understand the code (much less the rock star) a week after it's written. They tend to be parasitic, appearing highly productive but actually generating lots of unpleasant work (externalized costs) for the rest of the team. The call sign of the rockstar is the tendency to change interfaces willy-nilly and expect everyone else to adapt to his changes.
Those numbers add up to 95%. I'm going to leave 5% open to acknowledge that there are species of bad programmers I haven't met yet.