That’s partly a question of perspective. How is the input queue replenished? Is the team deciding for itself and worrying about whether they’re doing it optimally, or perhaps having work selected for them and worrying that they’re having their time wasted?
One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream. Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team. Horrible! Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.
Ultimately, only time will tell how valuable the work will turn out to be. Collaborate, be transparent about the decisions you make and how you make them, keep feedback cycles short. For maximum effectiveness in the short run, reframe the question from “how valuable?” to “what will we learn?” and refocus the work accordingly. If value is hard to measure and still harder to predict, you can at least learn to test your assumptions quickly!
Finally (and partly as a warning against getting hung up on the value question), remember that winning in long run depends on maintaining a healthy level of investment in capability-building work, alongside the more obviously urgent value-driven stuff. The alternative is to risk being left behind, and you need no ROI calculation to tell you how bad that would be!