I feel like this is probably more true than many of the people around would like to admit.

Very much like how there are plenty of proponents of DRY and SOLID but plenty of bad systems still get built regardless, even when trying to follow any number of principles along the way.

So you'd have to decouple what an architecture is supposed to (realistically) be, from any company-specific interpretation of that, which may not actually be doable. It's not so much the "No true Scotsman" fallacy (which comes to mind), but rather the fact that things almost always differ in theory in practice.

As an unrelated example, it would also be really useful to generate implementations from code models, like OpenAPI spec --> usable API client in language/framework X, or OpenAPI spec --> usable service stubs for the server in language/framework X, but in practice it never works out and most model driven approaches remain on paper.

Similarly, there are lots of ways to screw up your application architecture regardless of the specifics. Talking about which type is easier to screw up and in what ways, however would be a useful conversation to have!