Unless everyone agrees that the story is unnecessary or undesirable, there is usually no need or reason to remove it from the backlog. For the specific concern you raise, I don't see how outright removing a user's story is going to make the user feel more listened to. That said, if it has been decided (ultimately by the Product Owner) that the story will not be worked on (or is deferred to a later "version") the story should be marked as appropriate rather than constantly reevaluated. In my experience, you never reach the bottom of the backlog. It's completely normal that a story gets repeatedly deprioritized. This is part of the process of the "team" (in the broad sense) figuring out what is actually important. Most of the rest of this answer is really about how to deal the "risk" of a user "disengaging".
If a user is in a position to "track" their story, they are probably (or at least should probably) be able to be involved (at least as a spectator) in the prioritization process. When the story was added they should already have known its rough priority. If the user is actively involved, they presumably have other stories that are getting completed and should have little reason to "disengage". If the user is actively involved and all the user's stories are being deprioritized then either 1) this is a problem where features critical for a particular user are being deprioritized because it's unimportant to other users (or worse variants of this), or 2) the project isn't really aimed at that user's concerns and disengaging is probably an appropriate response.
In the (1) case, if the user isn't around to argue the case for why a story should be higher priority, get them involved. As a prelude to this or more generally, most probably in a sprint retrospective meeting but whenever, you should bring up to the team that you feel certain use-cases are being ignored which may potentially produce a system that is unusable for some users. If the user isn't very assertive, you or other team members may need to lend your voices to arguing for prioritization (of course, assuming you agree with the user). Some mild peer-to-peer "coaching" may also be useful if you feel equipped to do such a thing, or you can suggest it to a more appropriate person. For example, you may say something along the lines of "we want to build a system that works for everybody but we're constrained by the stack rank, so you should speak up and help people understand the importance of user story X". The important points to hit here would be a) explaining the process so the user understands how to work within it, and b) encouraging the user to advocate for stories that they think are important.
Things get more complicated (which is to say more political) if the user is needed for explicit (and to a much lesser but non-trivial extent implicit) buy-in. In this kind of scenario some "horse-trading" may be appropriate, though this is usually a bad sign. Ultimately, such a decision would come down to the Product Owner as they are the ultimate arbiter on prioritization. Since the value of software that is scrapped or just not used is quite negative, it can very much make sense to do some "unimportant" stories to gain buy-in. This kind of politicking usually happens at organizational levels higher than a developer, but you can definitely bring up concerns that the team may be failing to get buy-in from the users. This goes beyond Agile/Scrum. Agile methodologies try to use transparency and involvement to avoid these problems. In my experience as a developer, within larger organizations I've had to continuously and actively advocate for more involvement by end-users.