Architect, developer, tester, etc. are project roles that are inherent to software development.
The job title may say Staff Engineer, JavaScript Ninja, Principal Engineer, Senior Architect or any combination of the above, but in the end someone has to do the job.
When your company didn’t use the specific title of architect the role of architect was still distributed between different engineering levels. For example you had the role of X Engineer + Architect… this can work well if the project is mostly of technical nature and doesn’t require a lot of technical requirements elicitation, negotiation, synchronization and other people and organization focused work. Because if it does contain such work, you’ll be spending so much time in meetings that you won’t have time to write code any more.
Other companies assign the architect role to a specific person, or have multiple kinds of architects. An important duty of architects is alignment within and outside the organization and mediation between business and engineering.
In large-scale projects such work is especially important and can’t be done by someone with the title of developer, because they would probably get bored out of their mind and also not actually develop anything any more.
Neither of these approaches is wrong. I’ve worked with dev teams that expect to receive a design/spec that they will implement and at the other end of the spectrum with teams that love to design their own architecture. I will provide that spec for the former and I will make sure that their architecture remains cohesive with the platform architecture for the latter.
And it did happen to me that teams would insist on designing their own architecture and then create an over-engineered heap of code. Too bad for them, because they have to fix the bugs, but still ok for the platform, since all the interfaces and platform requirements mesh as they should.
Whatever level the architect is operating at, it’s crucial that they keep their technical skills sharp through building small prototypes, reading and analyzing code, code-review, etc. I can say from my own experience that whenever I neglected that, I started to become detached from the reality of the project and my decisions were poorer as my problem-solving approach became too abstract.