First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness.
Developers (often younger ones) that manically hop from framework to framework and sprint to sprint because design work is "too slow" end up expending more energy than if they'd just been lazy and really thought about what they wanted to accomplish before they worked on it. This is especially true in business, where that mindset is invaluable for skipping work you'd otherwise do while finding fit.
Second, I disagree that on a good team engineers aren't fungible: the fact is that, if you have one person who "owns" a part of the code, you are inviting disaster and bad design. This, and not its converse, has been proven to me over and over the last decade. Sure, one person might have the domain expertise or familiarity with something to really nail it, but they should never be the only one on the team who can do so.
If they are, you slip them pizzas under the door, make them happy and productive, and then sack them as soon as you can extract their knowledge for they are a liability waiting to turn into a problem.
Third, and perhaps most controversially, the author supposes that good design is important. For almost any business, sadly, it isn't. Nobody gives a shit when you have deadlines to meet and bills to pay--and if you're lucky, you can push that burden up onto the next poor bastard to inherit the codebase after you've cashed out.
I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed (and cleverly stood back up, but not because the majority knew or cared about design).