[JohnBooty]

    I argue that it's not time constraints that complex programs bad, 
    but instead the mere act of thinking that throwing more developers 
    at the work will make it any better. 

The bit about throwing more developers is true, but really does not follow from anything else you or the author is talking about.

    Treating the application as a "todo list" rather than a clockwork 
    of engineering makes a huge difference in the quality of the work. 
    When developers are given a list of customer-facing features to achieve, 
    more often than not the code winds up a giant ball of if-statements 
    and special cases.

Admittedly, this is often the case when doing feature-driven development.

But it absolutely does not need to be the case.

If you treat engineers as interchangeable cogs who only need to know about one story at a time, and never tell them about the medium- and long-term goals of the business and the application? Then yes. Then you get an awful code base with tons of if-then crap.

However, it doesn't need to be this way. If you give engineers visibility into (and some level of empowerment with regard to) those longer-term goals, they can build something more robust that will allow them to deliver features and avoid building a rickety craphouse of special cases.

I have experienced both scenarios many times.