Quality is in the of the beholder
Principle #2.
While it's true that code quality allows us to go fast, code quality isn't what anyone else sees. The code is only for the developers. High quality code is habitable code; but it does means nothing for the user.
I'm sure there are a lot of GUIs that are clearly created by a developer. Often the UX isn't thought through, or ... really... unable to be thought through. Developers can do UI, but rarely are they experienced in UX. The quality in the UX is going to be independent from the quality in the code. Quality code might make UX iterations faster; but there's no connection between them.
Both are quality. Both matter. Who experiences the quality aspect is different.
If the app hits a service, or a database, how that dependency responds can impact the perceived quality of the product as a whole.
Responsiveness can impact the perception of quality.
There is no single answer to what creates quality. It all depends on the perspectives and pressures the product is being developed or used in.
Some of these qualities will be in opposition. Faster time to market is detrimental to the quality of the code. Likely the quality of the product overall. If that's the quality measure we want; it's the quality want.
Developers can rarely agree what quality code looks like. Quality isn't just what we're looking at, but how we look at it. Our history and experiences shape what our expectations of quality are.
I've stopped working on computers because they performed so slowly that it was disruptive to getting work done. The lag spikes in the system were shorter than I'd regularly faced 10 years earlier. My expectations of how the sytem should behave changed over the years.
We need to consider quality of the system within the pressures it's developed for; and perspectives outside of what matter to us. This is why user testing is so important, gets lots of quality perspectives that are then optimized for.