This probably increases the accuracy of the work trackers but increases the B.S. level of management reporting in organizations where there are fundamental problems between management and the working level.(Which is the only reason anyone would want to separate these two things.)
While this probably seems like an improvement from the working level, it's probably bad for the organization. The solution is not dis-integrating communication tools so that management's view is not connected to the actual work tracking, but dealing with the fundamental trust issues. Which is hard, of course, but things that are important often are.
[EDIT] more to the point, I think if it worked we wouldn't still constantly see management surprised when things aren't delivered "on time", and yet, that still happens all the time. IMO the team needs someone "on their side" to report reality upwards, diplomatically, not their own work tools reporting up directly, or they'll lie to their tools, which leads to more surprises, not fewer.
I also think speculative future make-believe planning junk should be kept out of the real getting-shit-done tool. Put it in there when it actually matters. There should be no "on ice" or "phase 3" (when in "phase 1") crap in the tool the devs use. It may or may not make sense to have them involved in planning stuff that early, but keep the output of that planning away from the real-work trackers until it's closer to time to do it.
I think that's part of why Jira (and similar, heavy, report-focused tools) is so god-awful. It not only tries to have features for teams to get stuff done and for five other roles to dig around in tasks and reports for whatever reason, it enables and encourages that, and I'm fairly sure, at this point, that it's fundamentally a bad idea.