First, don't worry about sounding patronizing, when staying polite, one can say anything (almost )
Second, I have some experience with software development as business owner, business analyst ... of a few major developments and what you are escribing above sounds quite familiar
Voting (or "liking" to use more recent terminology) on feature requests indeed is not the golden bullet but it can be part of a priorisation strategy. It could allow to determine if a feature request is the wet dream of a single person, or whether it is broadly shared by the larger user base.
At some moment in time I used this together with complaint frequency, and "known bug" lists to identify priority clusters for development or evolutive maintenance. You may say that you already know where the issues are. I originally thought the same but structuring that knowledge gave very useful insights, resulting in increased efficiency, nevertheless.
I am however negative towards a "community decision board". It is the developer/owner of the software that should decide. On the other hand, involving users in analysing a functional area before programming starts may be a must have. In my experience, people who know their business (in this case travel and routing) even when having absolutely no IT knowledge, can add huge value in describing what they need. Then it is up to the technicians to decide the how.
Anyway, it is not up to me to tell you how to manage MRA, and that is most probably a very good thing too