I'd say that attempting to use the same tool to help a team communicate with one another and to communicate with management or stakeholders who aren't very close to the project (involved daily near the ground level) is essentially doomed. Management will either hate the answers they get or they'll ruin the tool's utility to the team, resulting in worse communication at every level and slower work. Or both.

It's where I think Jira and other do-everything tools that try to be useful to both ICs and management fall down hard, every time I've seen them used. Management wants to see their burndown charts and such. They want projections out months on minimal data. They want to see the performance of people, not teams. Points become BS because everyone knows they're being watched. Totals are missed the first few sprints (of course they are, you're still calibrating WTF a point means for this team and this project!) and management gets pissy, exerts more control, implies ICs are failing at their job, project goes downhill from there. But look, we're Doing Agile! Such professionals we are.

I think it has a lot to do with bargain power.

By using things like story points and other metrics intended to be internal to the team, developers have a lot of incentive to not lie on their estimates. On the other hand, management has incentive to push things to be finished quicker.

By letting management having access to those metrics, they're automatically at a disadvantage when negotiating timelines and priorities.

Management has, culturally, become very metrics-oriented. This is the root of the problem under discussion here. See Goodhart's law for a brief statement of why this can't work.

Almost every time I bring this up somewhere, someone pops up to say that metrics are important, key to fair and impersonal management. Without it, everything would suck, and managers couldn't do anything. The problem with that thinking is two-fold:

1. It ignores the fact that, as soon as there's a metric that determines someone's rewards and punishments in a management system (whether it's governmental regulation, corporate middle-management, anarcho-communistic self-management, or anything else), the system of measurement will get gamed, and the most overtly "successful" will end up being the most cleverly sociopathic about it.

2. There is an alternative to strictly quantitative evaluation. The alternative is qualitative evaluation. This requires good judgement, intimate knowledge of the problem domain, good intentions, and the ability to consider context, among other things. Sadly, this is incompatible with bureaucracy, which means you need to either carve a bureaucracy-free zone out of the larger organization to manage a team well or stay out of medium-to-large corporations (and out of small businesses that ape the behaviors of large bureaucracies).

Managers who insist on doing everything quantitatively (and sometimes they're forced to do so by their managers) will not get good results. "Good" is qualitative, not quantitative. Equating "good" with metrics just gives you results that look "good" on paper, but really aren't good.

Probably the biggest benefit of a small organization is the ability to eschew managerial bureaucracy in practice.

It is vital to have someone close enough to the project that the team trusts them to see their honest opinions about progress and blockers, including non-bullshit pointing of tasks, who is the point person for communicating progress to management, and who is capable of producing reports that are technically bullshit in an is-this-quantifiable-this-way sense but actually do reflect reality usefully to managers. Someone who does that well is worth All The Money.

They're useless if you're giving management direct access to team planning & communication tools, of course.

It really sounds like a "not true Scotsman" argument, but I've had Agile fail when the team failed to use Agile. As I wrote above, points inevitably became a proxy for time in one manner or another. Production was pinned to a certain number of points (say 15 per developer per sprint).

I can't throw it all on management either. People who should know better will accept 2 days worth of points for conducting training or attending a workshop.

Largely, though, I would say it's a simple matter of not understanding how Agile works at all. It has just become, "you score points for doing stuff" (in proportion to time, but it's not time, but it is).