> highest predictors of defects in a code base is whether or not the original team is still working on it.

Defects is a metric businesses doesn't care much about. If you have a good team that can create products customers wants, then it is better to have them keep making new products rather than maintain what they already have, then you can have less productive engineers perform maintenance, defects might go up but this way you will have way more products which businesses seems to care more about.

You would have a point if maintenance was something companies cared deeply about, but they don't. They want new products, and company specific knowledge doesn't seem to be very valuable there.

>Defects is a metric businesses doesn't care much about.

This depends on both the defect and the business. Just because critical regressions and recurring denial of service has become normalized as somehow par for the course in our line of business does not mean it comes without cost. It's all situational and subject to calculated tradeoffs but every shop i've worked with/in has classes of defects on the "Never Again" list, and sometimes on the "NEVER EVER EVER AT ANY COST" list.

from a different angle: "non original team" might have higher defects, but i propose that "non original team" without process or time to understand the code base would be more accurate.

changing people requires a time investment. and the learning curve is steep at the beginning

Not to mention vision that will change due to new ideas or influence that new staff brings to the team. It's not always beneficial for the project. It can go wrong in so many ways that it ends up being dead.

Don't get me wrong, change is good but too much change is just too much to handle sometimes.