If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
On those complex systems in particular the problems start long before any code is written.
A software engineer can create and understand the specs, requirements, design the system, architectural decisions, define everything about that software and data, model everything, failure, performance, operational topics, documents everything, etc. before a single line of code is written, and of course they can write good code. Then there are the coders who patch together chunks of code from Stack Overflow or whatever boilerplate they have in the company's repository. I know every coder likes to call themselves a "software engineer" but there's a world of difference between the two types.
For the first group code was never the hardest part. For the second group there was never any other part.
I don't think you're really disagreeing with the original sentiment? However, I think you're taking a much broader view of "code" than is intended by the original statement.
In your framing, you're kind of confounding code with architecture. Code is really just the act of making a computer do a thing you want it to do, for some definition of "thing you want it to do". Architecture is more about understanding which things you want the computer to do, and in which ways.
There are a million ways to code a task. That's the "code" the original statement is talking about. Understanding which of those ways is an appropriate way is a separate skill, whether you call it architecture, or something else.