there is a mass of statistics in product development identifying poor practices—poor in the sense of correlated with more failure, lower productivity, more delay, and so forth. For example, the COCOMO data shows that the capability of development people is the single most important factor for productivity, and low complexity the second most important. So, hiring lots of weak developers is not good for productivity. Executing a long sequential life cycle with a massive batch transfer of requirements (higher complexity) is not good for productivity. Research shows that iterative and incremental life cycles (for example, as used in Scrum) are correlated with less cost and schedule overrun than sequential development; therefore a large batch and long sequential life cycle case is not good for cost and schedule goals.
It is hard to argue with that. There is a huge difference in how easy it is to work with one person's code over another person's code. I would go so far as saying the best way to define a weak developer is one that does not understand how important it is to simplify their code and make it as readable as possible. Of course knowing you should do it and having the ability and determination to do it is another thing. My determination is growing but my ability is still trailing.