It would make sense to bring on someone with knowledge that isn't held in house (i.e., you need to interact with X, and no one is familiar with X, so hire someone for a few months who knows X backwards and forwards), on a contract to contract basis, but it doesn't make sense to do that for the entirety of new development. The cost to bring someone up to speed can be quite sizable, and you're looking at paying out that cost again every time you replace a contractor.

Similarly, I really, -really- dislike the idea of institutionalized discrepancies between "the rockstars who develop" and the "grunts who maintain it". Because then any problems with your code after the initial "it works"...are blamed on the maintainers not being good enough, rather than the fact you wrote it as quickly as possible, without concerns for long term sustainability. In fact, it provides an incentive to getting code written as quickly and sloppily as possible, rather than as robustly and maintainable as possible.