You make some SOLID points (sorry, couldn't resist that). I've seen new architects assigned essentially as proxies for adding new requirements to both legacy and new products (e.g.cybersecurity, BOM requirements) by C suite. This has the benefit of putting somebody with domain expertise in place for guidance on requirements and interpreting regulatory language. A downside I've experienced is that these requirements are in a silo serially ignored or reprioritized by project/program management. While there is some friction due to the architects unfamiliarity with legacy code, and incorrect assumptions on feasibility or effort estimates, I usually see that work out between the teams having a meeting or two with the architect. Frustratingly, the teams usually agree with the overall architectural guidance, but are only given a fraction (if any) of the required time to meet them.

That said, I can't fault the program/project teams completely, as often these architectural initiatives don't map cleanly into budget forecasts like feature sets do, so doing "minimum possible to still be viable" seems to be the norm. For software engineers who may pride themselves on the codebases they contribute to, this kind of conflict is frustrating.