Pushing a 90% solution through is a ‘win’ for the coder who is leaving, and hurts everyone on a continuing basis. It’s bad accounting, and lets the consultant look good for making the team perform worse (and look bad later).
And, IME, if that 90% solution needs a 100% rewrite after 40-80% burn in bugs and error chasing? What once was a bit behind is now way behind with staffing issues. Sunk costs don’t create extra budget.
Do It Right The First Time doesn’t always apply, only mostly always. Some people are insecure and territorial, yeah, but some know what their job is.
Entrenched engineers don’t want to you to alleviate or god forbid share the pain. Pain is good for employment security. And if the ship goes down, they’ll make sure they’re the last one to get fired, because there’s nothing the entrenched engineer fears more than having to job hunt.
I’ve been on all sides of this coin, and there is plenty of blame, misunderstanding, and bad ideas to go around.
The problem rather is: often good programmers have quite good ideas how these problems could be solved, but for "organizational politics" reasons they are not allowed to apply these solutions.
Thus:
Concerning (B): Because they are not allowed to apply their improvement ideas, they are the bottleneck. But being the bottleneck is not the root problem, but rather a consequence of not being allowed to improve things.
Concerning (A): It is indeed often the case that if you simply let someone else do the work, the code quality decreases a lot and in subtle ways. Good programmers are very sensitive (and sometimes vocal) with respect to that - in opposite to managers.