I was thinking something similar. In my anecdotal experience [1], large corporations can control variance by normalizing everyone's velocity. For example, in order for me to finish a feature, I had to write a document describing how I would solve the problem and convince my manager and tech lead that it would work. After spending about two months getting my plan approved [2], they let me implement it, which took me about four hours. At that ratio, the actual development time is practically negligible, so it's easy to have low variance. The side effect is that you also have very low productivity.

Imagine the opposite scenario, where they let me implement it first and then approve it if it works. Let's say it takes me a couple days to finish it (this time has to include some of the time that it took me to figure out how to solve it originally). Now the feature is getting done in a matter of days instead of months. The flip-side is that you can have higher variance, because if there's a problem with my initial implementation, that adds more time to fix the problem. In this scenario, the time it takes to finish features is more dependent on the engineer's ability than the time it takes to pass through the bureaucracy, and there's going to be more variance in the abilities of individual engineer.

[1] I worked at Microsoft as an intern in the summer of 2009.

[2] There were many days that I literally couldn't do anything except wait for clearance to go forward.

You're thinking of Parkinson's Law -- another well known finding in all industries.

A lot of comes down to how estimates are being used. A lot of places use estimates as the plan rather than ... an estimate. And that's where stuff goes awry, because as you say the incentives are to stick to the plan even if it's stupid.