If there is no priority, then what feature is most important to work on first. If everything is a high priority, then nothing is a priority. Prioritizing features in a rationale has made the development of a product a much better experience for all involved which translates to a better experience for the customer.
There are many methodologies that advocate for variable levels of priority. Off the top of my head, I can remember 3 different methods to prioritization (no kidding, I didn’t look this up). All those methods use the same basic process, assign it a level of importance. One I’m thinking of is MoSCoW which stands for: must have, should have, could have, won’t have. Right off the bat, you don’t care about the “won’t”, then you wonder about the “could”, then you sit there and debate between “must”/”should” and eventually start asking yourself “other than regulations what must we have”.
At best it becomes a binary decision between two levels. Other frameworks have the same issue, splitting it into 3-7 different “objective” levels where meetings upon meetings are spent deciding between should have and could have or medium priority and extra-medium priority.
Instead, put the backlog in order of priority. In theory, it sounds complex. However, in practice, it is much simpler. Here the focus is on finding where a given feature fits in the order of importance. The conversation becomes not whether the feature is of level 2b importance or really of level 2a importance. But rather, what is it more and less important than. Discussing importance in terms of other features vs in terms of an arbitrary scale keeps the focus on the criterion used when creating the feature vs the levels which are ultimately an abstraction from the feature itself.
In short, use a priority ordering instead of a lossy, possibly arbitrary, level of importance for assignment. Even if you used a level of importance for assignment, you’ll still end up with 100 high features you’ll need to decide on the order of. Just prioritize, to begin with.