Here is a scenario:
I am noticing stories lingering on the backlog for months while others are submitted and added to a sprint in short order. I see a risk that users watch their stories continuously pushed aside and disengage in the backlog/sprint process.
Is there a good rule of thumb indicating a story could or should be dropped from the backlog?
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.
As a member of the IT team it is your concern but not your responsibility to try to ensure engagement by the various business stakeholders. I'd say that only the product owner can remove a story from the backlog and they have to talk to the person who submitted the story, explain why it was rejected and smooth things over. Nothing would look worse that the perception that IT was deciding which features to implement.
It has to be a business decision, based on an assessment of how much effort (cost) the story takes compared to how much value the story provides. In any well run agile project in a commercially driven organisation, there will come a point where the cost of the next release is going to be higher than the business value provided. At that point you can choose to do the next release or start to transition the project to business as usual support and move any incomplete stories to production support issues for consideration there. Maybe, after a few months of BAU, the user story will bubble up and become worthwhile - on that basis I'd advocate not removing any story unless it really is hopeless.
Mcottle has already covered the case for bona fide stories never making a sprint very well. However there are genuine cases where a user story could be removed from the backlog altogether.
Not needed
These are stories that it was originally believed were needed but which aren't any more.
Superseded
These are stories which covered a small functional area but the work has been subsumed by another larger user story.
De-scoped
This is a valid requirement but one which is no longer satisfied by your team. For example, you may at one time have ensivaged having to design and write some software but on further analysis, you have decided to buy something in or there is existing software that can be re-used.
How you deal with these depends on your project management tool. Where I work, we have a junk iteration for stuff we definitely won't do which is kept separate from the main backlog.
