I believe it's largely down to short term goals versus long term goals. From the business perspective, the company should do things quickly because that means the jobs are more profitable, cashflow is stable, and the business team believe that they can always find more clients even if the product is horrible. This is the short term outlook. From the programmers perspective the company should do things slowly because…
As a consequence, what tends to happen, is that the project management tries to release as early as possible, and this is their primary role and they are accountable for it, but when you got a robustness issue in one or multiple customer site 6 months later, no one will ask the project manager to fix the issue, but the technical people will be under high pressure and will have to justify why the issue has not been caught earlier.
On the same vein, project management won't necessarily have any issue increasing the technical debt, since they might not be the one leading the next major product iteration, so they have the option to pass the debt to someone else so to speak. On the other hand, the technical team has never that option available.
This is an awful generalization, and some people are more mindful than other of the consequences, but this is a general tendency I have seen in multiple places. This is just another way to look at the long term with short term consequences.