Why users want strange things
Working with feature requests coming from users is a difficult challenge in itself. They tend to wreak havoc to developer sanity. They often contradict a previous feature or don't fit into the current architecture. You might start wondering if they really need the software you've built or an entirely different one.
But why is that?
When I work with users, I try to figure out what their problems are. The actual feature request is usually not that important. If it fits into the architecture / easy to do, I implement it. But for problematic ones, most of the time there is a solution that is better for all involved.
The root of the problem is users see the software and its development in a very different way. This, in turn, creates a communication gap and usually results in misunderstandings and a piece of software that is both hard to maintain and hard to use.
The long-term cost of features
When users see a software, they look at individual features. This is particularly the case for feature requests. They see a new feature as a one-time effort, similar to making a table or a chair. When the carpenter is finished, it has no effect on following tables or chairs.
A better analogy would be a cluttered room. If you want to build a new table, you need to make room for it first. So that you move existing features over and over again, which incurs logistic costs.
This captures the notion of long-term maintenance associated with the software a lot better.
Unless for trivial apps, users develop a personal workflow when they use a piece of software. They, in turn, have use cases they want as efficient as possible. Because of this, they'd like shortcuts that help them, which results in unusual feature requests.
If you go ahead and implement the requests without second guessing, you'll soon end up with contradicting requests. As different users have different workflows, amending one might break another.
This is a surefire way to end up with bad software.
If you build the features of only the vocal minority, you usually break the architecture. Users are usually better off with a consistent software than one that has all of their wishlist built into.
The other possible case is that you are building the wrong software. If most of the users want to use the software in a way it's not meant to be used, you should pivot and build a different one. But adding shortcuts won't do any good in that case.
Feature requests coming from users are usually for a particular workflow. If you implement all of them without looking into the underlying motivation, you'll end up with unmaintainable software.
When a request does not make sense, talk to users. Figure out why they need a particular feature. Then propose a solution that solves the problem and fits into the architecture.
Work with the users to build something they love to use. And don't treat them as they exactly know what they want.