I think there's also an element here of... when you work a long time on something, you tend to become emotionally attached to it, and you want it to be good and work well. Time to fix technical debt and work on making the product good is often implicitly waved as a carrot ahead of people who care about that sort of thing. "We can prioritize that after we ship $FEATURE."

This then feels like a betrayal on an emotional level when instead of a nice block of time to fix technical debt, instead the priority becomes $NEXT_FEATURE (the "features that don't exist yet.")

Management that can successfully keep the treadmill running ships features faster, so it keeps happening, and can contribute to burnout as (what felt like) implicit promises are repeatedly broken for the good of the business at the expense of the product.

Of course. Obviously a PM who isn't talking to the devs isn't doing their job.

But having said that, a PM is the person who owns the roadmap, and after talking to the devs, they may at times choose a course of action that goes against the devs' preferences (assuming the devs even have a consensus), because the PM has a lot of additional considerations. There are for example situations when the choice is either to crunch, take on massive technical debt, and still arrive at a feature with a somewhat lower quality than we'd like, or to lose a big business opportunity and possibly to have to let people go.

Most PMs that I've worked with are actually not that good at their job, and some were definitely detrimental to the org, but the good ones, who have an extensive understanding of the business domain and the technical situation, and have a clear vision (and strong opinions held loosely), are worth their weight in gold. And seeing how I did a short stint in a product role and don't want to go back to that sort of responsibility, I am grateful for the ones who are willing to take this on, and to take ownership when things don't go according to plan (and they usually don't, even in the best orgs).