Quality used to be perceived as one angle of the time-cost-quality project triangle. Unfortunately quality isn't as manageable as cost and time. If the funding is cut it is often possible to release a working product with the smaller set of features. It time is limited it is sometimes possible to hire the best specialists to implement all the features faster. It might sound like dropping some quality standards could be a way to releasing the product earlier.
The problem with this approach is in that time and costs of fixing bugs are unpredictable. Some bugs might take five minutes to fix, some might require re-engineering the core architecture. Whenever the quality level is cut, it is not only user-perceived quality that suffers, at the same moment a risk is added to the project. The unpredictability associated with dropping the quality level often make bug fixing one of the most stressful and time consuming issues on the project. I was working with the teams whose development at times was completely bug driven - weekly meetings used to go over the new problems reported to the bug tracking system and possible solutions for those. Working under constant pressure of unpredictable work that can come at any moment is no fun. It takes valuable time, effort and nerves.
Bug fixing often takes all the "spare" work time, leaving people little to no time for looking at the big picture and thus stopping the innovation process. Need to innovate more? - Make sure you create as little bugs as possible and fix them early.