The OP makes some pretty big generalizations:
> A common area for things to get messy is QA. In many agile teams, PMs end up doing UAT or requirements checking before tickets go live... A common way this happens is if the engineering team is much less tenured than the PM, and the PM knows how to test better than the engineers. In any case, PM acting as QA is not a healthy state. If PM is catching lots of bugs in UAT, engineering teams need to re-evaluate their QA strategy and fix the problem ASAP.
Well that's one possibility, but I've never seen it in reality, let alone call it common. Another strong possibility is that the team (PM in particular) didn't spend enough time thinking through use-cases and writing acceptance tickets. And/or that whoever's supposed to be communicating with the customer isn't doing that well. Or indeed that the customer themselves doesn't understand their needs well (in which case quickly getting them an MVP without much acceptance testing is entirely the right thing to do, then iterating - but ideally that should have been budgeted up front, which would be on the PM as much as anybody - and more so if they're "more tenured"). So, less blamespreading, more the team rolling their sleeves up. Especially if the PM really aspires to be a "partner" to developers (as they say elsewhere).
And btw if the "engineering team is much less tenured than the PM" is a recurring pattern, then that suggests trying to scale too fast, or antipatterns in hiring/ development/ budget/ management/ retention/ compensation (for example any developer with half a clue in that org would eventually either aim to get promoted/ jump ship into PM/ quit). The solution isn't always to whip the developers harder. It may be about mismatches in management/ budget/ incentives/ KPI.