I think you're probably right and that's definitely part of the issue.
However your assumption that people can all be convinced to agree on the technical architecture is part of the problem here. There are so many areas of software engineering where "reasonable experts" can disagree. Static vs dynamic typing, functional vs object oriented, loose coupled messaging based flows vs tightly coupled APIs etc. Successful systems can be built in all these ways as long as one is chosen and there is some consistency. But it is hard to be successful if they are built in all different ways at the same time.
So inherent in this picture is that you will have people with irreconcilable differences about how things should work at a fairly deep level.
Acknowledging your point however - part of what I say my mistake was in not "intervening" was to do more of this advocacy proactively, and flush out earlier on - can these individuals be convinced or is the difference irreconcilable.
An example, if it helps, is in one instance one of the team was tasked to implement a particular feature, and they found that the implementation was too slow when written in Python. So without consulting they selected a different language that is not in use or understood by anybody on the team at all, and then developed this whole critical subsystem in this language. Meanwhile there were many alternatives within the team's chosen tech stack that could capably solve this problem with adequate performance (even Python if properly utilized). The solution was an amazing work of art (although quite buggy as it turned out). But it was a disaster for the project and actually sank the delivery of it.