>The project manager, of course, still needs to be able to make an estimate according the his team's velocity, which he can then communicate to other business divisions.
PMs who can successfully and reliably handle this kind of analysis and forecasting for their team are more rare even than high-end software developers (in my experience in nyc startups, may be different elsewhere). And they can be far more expensive, because these skills apply heavily to things outside tech as well, so you're competing in a larger employer pool than developers.
The reason, I think, that (immature) companies use these sprint/deadline frameworks is that it puts the entire burden of everything complicated onto the engineers (estimation, forecasting, figuring out how to meet deadlines, incremental delivery, progress communication, GANTT charting, road-mapping, etc). They focus all their budget on hiring "good engineers" and then try to localize all the "hard" stuff there within engineering, and then they decide they can skimp and hire underpaid former consultants to be "product managers" where all they do is check boxes on a requirements list, and play the telephone game between deployments and engineering. It's literally creating the role of that guy in Office Space - "I'm a people person." These people will also never be able to gain enough control of product direction to challenge anyone in leadership over anything.
Company leaders seem to have some vague notion that this will somehow all work out in the long run by framing this whole thing as "being agile," and "not sinking too much resources into things that will change," yet all it is is lack of proper project planning abilities and a fear of owning risky decisions. It's a culture utterly lacking in leadership accountability. If everything is "wait and see," or, "ask the engineer for a commit- cough I mean 'estimate' for when it'll be 'done'," then nobody can ever be held accountable for bad leadership decisions or for improving their decision making skills over time as they learn and grow in a leadership position at the company.
I know this comes off kinda conspiracy-theory-esque, but I have a feeling that many of these systems develop in order for the less-skilled-but-scrappy initial engineers/employees who were friends of the founders to retain control as the company grows and develops the resources to hire far more skilled (but more risk averse) employees. Far too often you have someone who is perfect as a founding engineer and VP of Tech for 10-15 initial developers, but does not grow their experience to match the exponential growth of the company, so they do NOT have the experience to be CTO of a 100 engineer tech team several years later if the company takes off. But now this person has been through "war stories" with the founders/C-Suite, and the other execs can't bring themselves to realize that the person is now a huge burden on the company, because the other execs are also mostly in over their heads as well at this specific point in time (high growth).
One good way to judge if this is the case at a company is to see if they have an "engineering IC career ladder" and see what skills they decide apply to "senior" IC engineers. It very often ends up being things outside engineering that appear at the higher rungs of the ladder, even though it's supposedly an "IC" ladder, because they can't figure out how to hire the proper roles for those things, and can't do them themselves. It's crazy to me how many people seem to think a very experienced engineer should be working on GANTT charts and roadmapping instead of systems architecture design & maintenance, and high-complexity-scale technical change management, not to mention R&D and onboarding/training.