Right, and I think the example here is instructive. He's not talking about rushed, shoddy, buggy code. He's talking about not taking the time to implement the right design. The resulting code might work just fine and doesn't necessarily impose additional maintenance costs, but the design issues mean that every time you're adding or modifying a feature you have to do extra work to translate from the 'correct' theoretical design of the feature to the actual design.

Unfortunately, while managers are often happy with "it'll make page load faster" or "it'll increase uptime" as a justification for a project, and "it'll reduce bug reports" and even sometimes "it'll automate manual tasks", "it'll make development easier" can be a really hard sell. It sounds pretty abstract and I think some managers start to think that it's just an excuse. It's certainly hard to quantify the impact, especially if you're expected to do that in $/yr.