Doesn't matter. Manager has saved costs on the project and looks good for it. They move on while a new manager handles the support/maintenance issues and the higher ups just become convinced that support/maintenance just happens to cost a whole lot of money.
Contracted code quality becomes a standard to be gamed. They'll have plenty of comments, but how many add useful information? It may pass a lint, but the architecture will look horrible. The database may be normalized, but the people and accounts will both own money, but there will be no way to link people straight to accounts.
I have done both. The devil is in the details, they can meet some guidelines but wiggle out of others. As stated it becomes a game. As such it is imperative that you spend a lot of time coming up with the metrics you will use to determine quality. Be VERY wary of anything that has lines of code in it
Overall it has been my experience that you pay multiple offshore resources to get the output of 1 onshore resource. If you bring them from offshore to onshore their productivity does go up some. The caveat to that is they do have really good QA teams and I wouldn't hesitate to leverage them in that role.
Have you yet figured out a metric that encapsulates code quality? Any metric you name, I can find a way to game it.
The only way I can see is to thinly slice the system enough and to require business peer review and daily demos on all slices to correct bad systems earlier. This also means you need a top engineer devoted to babysitting on behalf of the organization, and a good enough engineer to handle the code reviews can probably do the job better than a team of remote mediocre engineers.