I've heard many times that refactoring is mainly used to make developers happy but does not add any business value. This is partly true as refactoring is not supposed to alter behavior and therefore adds no business value. As for making developers happy, I'm not really sure about that. Not refactoring keeps developers in a coding mess. Nobody likes being in a mess. This is why developers are relieved after refactoring.
With that begin said, let's move on to good architecture. The "soft" in software stands for malleable, changing. Software architecture should be malleable. Usually, architecture stands as a pillar in a software project and architectural decisions are seldom revised and even less criticised.
Failure to change software architecture when necessary is similar to lack of refactoring
Consequences can lead to a poor project no one wants to work on.
The key to having a flexible architecture is to decouple intelligently. Practices such as Hexagonal Architecture aid in keeping technical aspects far from core business implementations. It's not easy but it can help a project grow in a more agile way, as business needs get clearer and as technical constraints emerge too. Imagine if that flat file you used to search clients is not scalable anymore? Time to use a relational database? And what if this relational database is not fit to withstand traffic? How about changing your data source to a clustered cache?
Just like refactoring code can keep a projects time-to-market stable as the number of features grows, refactoring architecture can also help being able to adapt to a number of ever-changing needs.
Architecture holds the structure of many software and is rarely changed because of that. Architecture should be prepared for change so it can be replaced easily. In an ever-changing digital world, adaptability is key. Keeping a door open to changes is the best thing a software can benefit from.