A real statistic against your claim is one of the 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.
changing people requires a time investment. and the learning curve is steep at the beginning
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.
Don't get me wrong, change is good but too much change is just too much to handle sometimes.