Code quality is actually quite distinct from an applications feature set. Something that was vibe coded in a week can have similar features to something that took 2 years for a dev team to bring to maturity, however the actual code base will be on a completely different level. Not all applications care about all of these things: Security, scalability, stability, performance, low resource consumption, test coverage, readability, effort to customize and extend.

If you are creating a dating app or a device driver you will naturally have different preferences for the code base.

The end users opinion is secondary to the opinion of the company or person who owns the software. The software is an asset that the company uses to run its business. If pissing off 50% of your user base is acceptable business strategy, then they may opt to cut corners in places which will result in dissatisfied users.

The real question is what is the goal of the company. Most companies main goal is profit, but in some cases like nationalized government services, non profit organizations, providing a core service offering is the main goal. In the latter case it may be acceptable to have shitty UI and some broken parts of the application as long as the important functionality works.

Then there is the tradeoff between investment (good developers are usually not free) and essential vs nice to have features. Maintaining a minimum viable product is non negotiable while assessing experimental features for market desire will have a reduced budget and have more tracking for return on investment.