People don't normally try to rearchitect their personal homes into skyscrapers while they are living in them. But as a software company scales, people face the morally equivalent problem in software all of the time.
That fact makes the key design principles different. Fully a third of the bullet points on this cheatsheet speak directly to the needs of making that kind of change later.
I'd go further than this, if this is confusing architecture with development. This is not to say that a senior developer or systems engineer could take on an architecture role: but this wouldn't be the check-list in my view.
An architect is more likely, like his building counterpart, to see the system from the top down. That is given a clean sheet of paper: How can we achieve the availablility and fault-tolerance we need? what is the threading model? how does the system connect to the outside world? etc...
Whoever takes the role of doing this makes sure that the direction of the implementation doesn't loose sight of these goals. He may even create non-functional requirements.
All points certainly apply in all forms of architecture, but some points are more pronounced for particular forms. Even if depicted the same and having the same gravitas, the manifestation of the point varies.
Testing, for example, is obviously paramount in architecting buildings because failures can be horribly expensive and lethal ... but software development is too often prone toward "happy path testing".
Repeating is more problematic in software thanks to Ctrl-C / Ctrl-V, whereas other disciplines have nontrivial time & cost sunk in doing something more than once.
Cost of changes is profoundly different. Since building software is nigh unto free (click "build", wait seconds or minutes) instead of costly (bridges take months or years), those involved are too often seduced by the notion that changes cost nothing.
