I think the disconnect here is that the majority of architects I've worked with haven't been "good" in a technical sense from a "actually building software" perspective. I'm assuming this is true for a lot of folks here, based on people's responses in this thread.

The day to day of some of these roles has been:

* sit in meetings with high-up product managers and biz leaders

* come up with pretty diagrams of how to totally re-build (sorry, re-architect) the system. Often this is jargon-heavy - protobuf this, envoy that, circuit-breakers the other thing.

* talk engineering management into this plan

What's been meaningfully missing is the details of point A -> point B to achieve their plan. None of the jargon is necessarily wrong but it's not grounded in the reality of the current software systems at all.

This comes about when the technical VPs aren't hands-on with the system anymore either. If non-technical leadership is saying something like "improve uptime" and you go get hire an architect into the company and you'll get a lot of presentations about things the devs on the team may already know about but haven't been able to get prioritized, but it's still on the existing devs to actually build it.

"Paying someone fancy to convince non-technical business leaders to let the devs build what's needed" isn't necessarily a bad decision from a CTO or SVP of Engineering, even! But the devs who have been saying the same shit this whole time only to now see the credit go to the higher-ups and the new architect, after getting the blame for the old status quo, don't exactly have a positive view of the architect's actual engineering competency.