Here’s the thing about software built for a business: that software exists to serve the business’s bottom line, NOT some abstract ideal of software perfection.
Is this example a little egregious? Perhaps.
But management has pressures of their own to ship software - many of which are not flexible when quality is at stake, and many of which have hard deadlines. These pressures come from regulators, competitors, investors/the board, or sometimes simply cash flow.
And if you want to fix the bugs after shipping, your job is to make a (preferably quantifiable) case for why and how that will be better for the business’s bottom line in the medium to long term than not fixing them.
