Software architects usually interact with the clients and stakeholders of a project. They - ideally - will need to be involved in figuring out exactly what kinds of requirements the client is looking for, being able to make sure the requirements are business requirements and not just "make this page have a floating top menu bar."
Total aside: Yes, I've been on a project where we literally spent hours of meetings with CEOs of two large insurance companies just to decide whether to use a floating top menu on the web site 😜. It happens...
Anyways, the architect needs to make sure that the technical direction of the project is viable/feasible give the business needs.
So there are two primary parts:
Knowing multiple programming languages, paradigms, etc. as mentioned in the "question" of this post are helpful because every language and paradigm solve specific and different kinds of problems.
If you have a business, for example, who needs a system that will be developed and maintained by hundreds of developers, then you need to know that there are specific patterns for building these kinds of systems (DDD, Microservices, etc.)
Imagine the need for an e-commerce site which needs to keep the data of all user interaction with the site (via products ordered, products added to cart, products removed for cart, etc.) so they can do analytics in the future (I.e. predictive analysis, etc.). Knowing that Event Sourcing can solve that problem would be applicable here.
So, a big part of being a good architect means your knowledge is broad enough that you at the very least know what technologies are available to solve which problems. And you can figure out what business problems map to which technological problems and solutions.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.