The article does generally reflect what I've seen - not only with outsourcing, but also reflects the general cultural predisposition of people that I've worked with, in the US, from those places.
A bit on India with the churn that was mentioned I've seen explained as that it is difficult to get a promotion within the company - you need to get hired by another company to move up. With one contract shop that I've worked with, over the course of 18 months (we worked with them for three years) every developer position was replaced with a new person (so twice across those three years). This resulted in a lot of loss of institutional knowledge of the product. You'd train up a person, they'ed work on it for awhile, and then move on to another company and train their replacement. That training process was always lossy.
The goal for a ((stereo)typical) Indian developer is to be where the pay is best. The way that the companies are structured (and note other comments to the effect of the pay scales) is that this is in management. One gets to that by demonstrating management potential rather than technical skill. The highly paid sr. developer path isn't as viable as the (comparably) highly paid jr. management.
Another major point that didn't appear to be touched on in the article is the intellectual property leakage and protection. Many managers here are afraid of that (rightly?) and take significant effort to make sure that overseas developers are strictly limited to what they are working on. Sometimes that goes as far as "you have access to _this library_ - not the entire application that it is part of" (or for that matter, even the integration test suite - a build breaks because of a library change... and you can't provide the full test to show how it broke) leaving the integration to the in house team. That can cause some friction in the development process that is often unaccounted for at the start of the project.
About churn, promotions are one of the issues, and the other is a good salary. Many companies are quite exploitative (that's one way of looking at it). If you can't play hardball with your HR, your freshly hired subordinate's salary might end up being much higher than yours. One way that HR can operate is to reward talent and productivity. The other way is to reward negotiation skills.
I can't empathize with the other points that the author made about India -- because I've never worked on an outsourcing job.
A bit on India with the churn that was mentioned I've seen explained as that it is difficult to get a promotion within the company - you need to get hired by another company to move up. With one contract shop that I've worked with, over the course of 18 months (we worked with them for three years) every developer position was replaced with a new person (so twice across those three years). This resulted in a lot of loss of institutional knowledge of the product. You'd train up a person, they'ed work on it for awhile, and then move on to another company and train their replacement. That training process was always lossy.
The goal for a ((stereo)typical) Indian developer is to be where the pay is best. The way that the companies are structured (and note other comments to the effect of the pay scales) is that this is in management. One gets to that by demonstrating management potential rather than technical skill. The highly paid sr. developer path isn't as viable as the (comparably) highly paid jr. management.
Another major point that didn't appear to be touched on in the article is the intellectual property leakage and protection. Many managers here are afraid of that (rightly?) and take significant effort to make sure that overseas developers are strictly limited to what they are working on. Sometimes that goes as far as "you have access to _this library_ - not the entire application that it is part of" (or for that matter, even the integration test suite - a build breaks because of a library change... and you can't provide the full test to show how it broke) leaving the integration to the in house team. That can cause some friction in the development process that is often unaccounted for at the start of the project.