The product manager's lament (why do I have to rewrite specs five times?)

This is essence of the problem right there. If the developers aren't involved in the design of what they're building, you have a broken process. The idea that you can "skimp" on talent such that you're hiring people to implement things you wouldn't trust them to design is pretty flawed; it means that you're developers are going to be producing a lot of crap by failing to see or find implementation-time improvements to the stuff in the abstract specs. And the idea that you can get that design right the first time at all, without having written a line of code, is fundamentally flawed.

The rest of the suggestions in the post seem to be attacking this solution sideways, by involving the developers earlier, iterating the specs, etc... But it doesn't seem to recognize the core problem. You can't "hand off" low-level specifications to someone other than the implementor. It doesn't work.

Whoever came up with "the pipeline approach", or thought it would be a good idea, had never actually worked on any part of a project before. The reason the pipeline approach fails is because the people with the most knowledge about what is possible are at the end of the pipeline, and for some reason they are kept there. The implementers need to be learning the process they are implementing, before a spec is even written. I bet the majority of everyone's career has been spent being told to implement impossible requirements, or admitting that the requirements aren't actually impossible and having to say that the company doesn't actually have the time or the money to implement it (which is the logical definition of impossible, if not the physical definition).

This is, for me, one of the most important things we've learned in software development: self-empowered teams with a common goal can do things that compartmentalized teams cannot.