There's a dichotomy in development where bad PMs can prosper in a way bad engineers can't.
There's no skill test for PMs, unlike engineers. Bad PMs can look like good PMs to senior management simply because they hold tons of meetings, kiss ass, over promise or steal credit. Any of those bad traits can fool senior management. But those are bad PMs.
On top of that, when you have a bad PM, there's a good chance the Devs themselves will step into the role and still deliver a product.
The bad PM will still take credit, obviously. A bad PM is often circumvented instead of exposed.
Conversely the opposite doesn't work, a good PM + bad Devs turns into never ending dev cycles. The PM looks bad even though there's nothing he can really do, unless he can fire/hire. The good PM cannot circumvent bad engineers.
And in the end, to find bad engineers you can just look at their code. If you don't have the skill to do that, or don't employ someone you know that can, you probably shouldn't be in the software development business.
I challenge the idea that there is no skill test for PMs, though - take a PM interview at a serious product company some day.
And the PM role is of course more than just delivery. If they dropped dead the product would still get shipped. But then what? Someone would need to talk to customers, dig into data and figure out the roadmap. Other people can do it, but in a sufficiently complex company you might as well get people who are good at it and want to devote their time to it.
I understand why some engineers don’t like PMs. But it is exactly the same reason as why some PMs (and C-suites) view engineers as fungible resources who waste time on abstractions instead of shipping, and pad estimates and refuse to discuss practical tradeoffs to move quicker - it’s an unfair generalisation based on bad experiences.
I just think more respect all around wouldn’t hurt.