Architectural soundness is sound business
The internal structure of the software, however, is not something that’s directly perceivable by the user. I can’t tell from using a program whether its internals are constructed well or not. Internal quality is thus a more hidden attribute. When someone says we should do things that reduce the design quality of a system to build more features, that person is applying the tradable quality hypothesis to internal quality.
The trouble with doing this, is that if internal quality is tradable, then it makes no sense to put any effort into internal quality at all. If a good design stops us from adding features and provides no benefit to the user then why do it?