It’s more than that though. Once the list is sorted, the next time you come back to it, the list is still more or less in the right priority. So the work for prioritization becomes easier.
That doesn't seem the case in projects I worked with. In my case, there were more features than engineers and some features were more important than others, so the list made sense. Obviously, it's not set in stone. Features can sometimes jump queue, be completely dropped, or more important features can show up. But I don't think I was ever in a position when a broad list of tasks for the quarter didn't make sense.
Features are emergent out of solving the business needs. If you see a business opportunity in toasting bread, it wouldn't make sense to have an outstanding issue that says "Affix fireplace to the bottom of the apparatus". Instead, knowing your business goal, you start to think about how bread should be toasted and when you come to the revelation that an electric coil is the most efficient method to solve your problem, you finish adding it to the product and then revisit what your next business need is in the context of what now exists and what you have learned in the meantime.
Issues only come into play when your understanding is wrong, to serve as a reminder to revisit your assumptions. New features don't fit. If you are spending so much time finding features to develop faster than you can develop them, your human resource allocation is flawed.
It all depends on the business and business model. For instance, I worked in a classroom app. We had a few goals per quarter but let's just see a couple. For instance, one goal at a certain point was to create all these new lesson types. However, some were clearly more important than others (the ones which were used in almost every lesson was more important than one that's used in a couple. For bigger lesson types there may be more than one issue. For instance, being able to select a single option in a multiple choice lesson can be done before the feature to allow multiple selection and things like that.
Another goal that would frequently appear is paying tech debt. Some changes are also more important than other in that track.
All this work has business value and may be part of the BAU of a established business. I think you're describing a business in a very primordial state. Although, even in startups I've created having a list of things we wanted to do was helpful. We saw our competition we wanted to do better, but we also need to catch up. Lots of things are just obvious and not all the work one does is revolutionary. I don't disagree that changes do occur, though.
