When prioritizing order in which tasks should be executed agile approaches give top priority to tasks with the highest business value. There is a very good reason for such approach. Namely, for too long software was built like a cathedral that becomes useful only once a roof is put on top of it. Similarly, in many software development projects managers and programmers have built all the intricate back end infrastructure, only to find out at the end of the project that the overall functionality delivered is not what users wanted in the first place or no longer needed due to changed business environment. Agile approaches therefore try to avoid layered construction of software systems and instead strive to approach software development vertically, that is, by building a particular functionality end to end and putting it to use by end users. But optimizing only for business value, might lead to a product or technological dead end. Even though that each individual product or technology decision made sense, we can end at a local peak, face a cliff or stand in front of an insurmountable wall. In the case of software finding yourself in such a local optima causes either product pivots if the product is not right or the dreaded rewrite if technology is not right. To prevent such outcomes from happening it pays off to prioritize not just for a maximum business value but also for a maximum amount of learning about the risks we might encounter in the future.
Unfortunately, I've seen way too often this argument abused by engineers to push through their technological agendas. And if engineering zeal conspires with wishful thinking of product managers, we more often than not end up with over-engineered solutions.