If the delivery team members in our health insurance example were being held to the metric that my friend was having imposed, they would most likely create a backlog filled with stories that introduce many of the features identified via the impact mapping exercise. However, because they are acting more from the scope/time/cost paradigm, they are likely to commit to a certain number of stories and strive to get those done. Even if they deliver the web-based claim form first, they may actually be incented to keep delivering functionality. Even though the web-based claim form solved the problem, their actual delivered story points may end up being considerably lower than their forecasted points, especially if they have to provide a forecast at the beginning of a quarter. The same would happen if the delivery team assigned value points to their stories. It's true that this relative valuing may help with making priority decisions, but it wouldn't stop the team from potentially delivering more than they needed to in order to meet the specific metrics. The trouble is those specific metrics are looking at the wrong things. The number of value points I deliver in a quarter doesn't tell me whether I helped a stakeholder solve the problem.
My ScrumMaster friend doesn't work at a health insurance company, but she does work at an organization that has just started adopting agile approaches and is typical of many organizations making the move, in that delivery teams seek to understand and utilize all the practices, but their leaders are reluctant to adopt the mindset shift that is necessary for effective efforts moving forward. They tend to ascribe to the idea that you can't manage what you can't measure, and they seek to equate things in agile approaches based on their existing paradigms of managing scope, time, and cost. Unfortunately, that paradigm does not always lead to the best outcome for the stakeholder.
A focus on value—truly seeking to solve your stakeholder's problems—will lead to the best outcome for the stakeholders. By starting with value as defined by solving your stakeholder's problem and seeking to solve it in the most efficient way possible, it is very likely you will be able to keep within scope, time, and cost constraints much easier than when you start with a laundry list of things that you want to do. Starting with value first is truly the way agile approaches can make things cheaper, faster, and better.