I think that whole paradigm is a bad idea, but I also think that if you've already decided you're going to use one of those languages and run your project that way, it does make sense to have a person responsible for the high-level system design.
IMHO this is one of the worst ever ideas in software development - largely as if you never actually get your hands dirty with real code and the whole messy business of getting it developed, deployed and actually used you never actually see what actually works and what doesn't.
Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.
The point is, the larger the project, the more important it is to invest in the right expertise at the beginning. The problem we have in software engineering is that successful projects almost never start from a position of major financial backing. Instead, the usual process is, start lean and cheap, hopefully gain traction, grow the product, get the investment, hire the talent. Honestly, I think it's a miracle if these types of projects are ever recovered.
If you tried to build equivalently detailed software blueprints, you end up just coding the whole thing. The problem is, the software is the blueprint.
Casey Muratori summed it up best in a handmade hero episode. He thinks that a better analogy for software architect is an urban planner. I think that if you approach your design phase more like urban planning, you'll accomplish most of what the article author is going for.