Software Architecture & statgegy is a voting production department team
The best argument that can be made for “Software architecture & Strategy” ( “SA&S” ) came from one of the production teams leads.

“That is not how we develop software, we do not need it..”

Software architecture - Wikipedia*

Looking back Joomla has failed to be successful in putting out consistent quality or “approved” code (i.e UCM, Tags, Custom Fields). Typically development starts when somebody feels that there is an itch to scratch, Then at the time of a pull request some other developer with the same itch will comment and possibly things have changed around (as with custom fields).

Worst case the changes go in “unnoticed” and we end up complaining afterwards (as with tags). The end result is we have frustrated developers that feel their time was wasted or an unhappy community wrt a sub par implementation of a feature.

Feedback on pull requests is always valuable, everybody's effort is appreciated and the mechanism should be cherished. There is however a way that we can improve on this, whilst lowering frustration and increasing professionalism.

If we look to professional software development in the industry a reference is always made  to architecture, the blueprint for how functionality is to be added/modified and with what constraints. Software architecture helps to reduce the chance of failure and minimise risk*. The architecture view is the helicopter overview he is not typically the developer.

If we use a comparison to a building and its associated architecture, the architect is not a mason, plumber or electrician ( he might have been in the past). They architect defines framework for the foundations and layout that is built on top whilst estimating how much of what (bricks, cement, etc) needs to go where. Architecture and Strategy go hand in hand in that comparison as the size of the plot and the strength of the foundation laid on top of it is the cornerstone of future strategy.

Joomla lacks a “body” of developers that the production department can turn to for questions on architecture and support. Joomla also lacks a body that has the skillset to structurally review larger functional improvements such as workflow and a rewrite of tags. It lacks a body to lay out a technical foundation for the future. Having this body to reference would help the developer implement the best possible solution by having an “encyclopedia” of knowledge to go to when it comes to major decisions.

That advantage of having a body of people, instead of an individual, to advise would also mitigate the point of individual criticism. `I discard what person ABC says because he's always…. Having a body to advise/help should also help continuity as knowledge and history should be anchored in that body and not in the head of a single individual.

Having a balanced group shall also ensure a balance between a “hacked” and “theoretical” architecture approach.

The architecture and strategy team shall play an advisory role within the production department.

Its actions can be triggered from within the group itself or from de production department. Its focus is explicitly technical.
Overall project strategy is more than technical, Joomla’s roadmap should consider more than technology alone, for example marketing.  There is no structural way of doing that yet, that's a discussion at another level. A representative of SA&S should take part in that, but requests should always flow through the Production Department.

For sure there will be challenges to overcome because for the lack of a better word we are a collection of ego’s, both inside such a body as in the developer community. Careful and Mindful communication would be key!

It is proposed to rebrand Joomla!X to “Software Architecture & Strategy”, there is a 90% overlap in goals. The big difference being the lack of coding and explicit focus on advice.