One computer science guru put it this way, paraphrasing. "Anyone can build a dog house. And a cathedral is really just a gigantic dog house. So you build your cathedral and it collapses, because the more you scale something, the more architecture becomes more important than process. You can either then go learn sound architecture or pretend the collapsing building was the desired result."
This is not entirely true, as I've worked on projects with unsound architecture before and what usually happens is that instead of collapsing, a gigantic wooden beam gets propped up to support the cathedral from collapsing.
Except it gets in the way, so now you have to build around that gigantic protrusion, making any new additions to the cathedral take much longer than it should. Over time, more and more of these protrusions and add-ons and workarounds get tacked on, until even the most minor change involves navigating over a land-mine of bad choices and bad architecture, slowing any new development to a crawl.
When something is properly scaled and architectured out, adding new features is easy because the system is designed to scale. Since the goal of software development is to solve problems using software, proper architecture is about learning how to solve larger problems in a shorter amount of time.