Even when the possible goals are identified, someone has to prioritize them at some point, since there are always more goals you
could achieve than goals you
will achieve. To prioritize, you need to know both the benefit of a goal (which is really a probability distribution, not a number) and its cost (which is notoriously a wide probability distribution before you have done it). Sometimes this involves trading off the needs of different "goal donors"; in XP these all filter through a single "goal donor", confusingly called the "customer", who decides how to order the cards in the box once they're estimated. The goal donor (who may or may not be the gold owner, another confusing name) can reorder the cards at the beginning of each iteration, either because new information has appeared about the benefits, about the costs, or about the possible goals.
It sounds like what you're describing is the lack of such prioritization. It isn't necessary to keep the developers ignorant of new user "demands" in order to prioritize them; they just need to be empowered to follow the priorities the team has chosen instead of accommodating every demand.
Sometimes it's easier to accommodate a demand than to write up a card and estimate it, though. Sometimes a bug fix or layout tweak is obvious enough that doing it takes only a minute or two; then, it's just a question of process overhead whether the actual cost of doing it is five minutes or five hours: potentially multiple forwarded email round trips, a fresh checkout, pair programming or other code review, compilation time, test suites, commit comments, merge requests.
Usually, in my experience, if you have extreme overhead, most of those changes never get requested, because they don't get prioritized the way they would with the order-of-magnitude lower cost a lightweight process can provide. The result is that they never get done, so the product is full of easily observable minor problems, which is experienced as shoddiness.