Kanban allows for critical fixes/features to jump ahead of the line and its obvious what work is getting traded off for later. Kanban also flows very nicely with a CI/CD process where when something is tested and ready to ship, it gets shipped. I believe the essence of agile is these two concepts - shipping working software and lean prioritization. Things getting stuck in a backlog is a good thing because that shows they aren't that important (other things keep skipping ahead) and you aren't building, testing and delivering software that is hardly used.

As a manager in my org I'm not driving deadlines, that's the PM and they mostly know what can get done and are reasonable. Its expected that if you keep jumping the line with stuff, other things are delayed. One downside that is concerning is focus time on specific areas of an app for developers and tech debt in those areas. Its like they keep hopping around from tree to tree like a squirrel. People that like long projects where they are 95% of the time building new things and don't have to deal with production issues, bugs, etc. this org and work style isn't for them.

But a manager might want to have at least a rough estimate of how much something costs before deciding what to buy. That is, they might want to know roughly how long something is going to take before deciding to put it as a high priority item.

It's not the manager's job to make technical decisions or choices of this nature, or at least it really shouldn't be.

The manager should be there to act as an umbrella and protect the engineers from the morons, the technical leadership leads the engineering team, and they make choices on what is high priority to get things done.

By "management", I meant people including product management.

Product management absolutely makes decisions like that.