"...finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work.
The question is, should bug tracking and feature tracking be different, and can you use a single system to do both as well as schedule iterations/milestones/etc...
In terms of a "pure" Agile approach, you allow your team to use any combination of tools and processes that works well for them. Sure, you may find a single product that does everything, but perhaps it doesn't do some things as well as you'd like. If you run multiple systems, you need to determine just how integrated they need to be, and if any integration is needed, find the means to do it, and decide just how much information needs to be duplicated. It all boils down to a cost/benefit situation, so naturally any system employed needs to take into account the impact on a team's overall efficiency.
Where I work, we use a Redmine system to track bugs and features in a single system for multiple projects, with links between each project where dependencies exist. We create labels that relate to milestones, which for us are effectively long iterations that may range anywhere from a matter of weeks to a matter of months. For individual tasks and features, we tend not to track iterations too closely, so we have no need to worry about burn-down charts, white boards, sticky notes, feature cards and all of that stuff, as we've found that for our specific needs, some of this stuff is overkill. Each feature itself effectively represents small iterations of between 2-10 days duration, and for those that might care, we log our estimates of time versus actual time for later analysis. This may sound a little ad-hoc, but works for us and ultimately our real measure is working code within a series of time frames.
I suppose if we decided to employ another more formally "regimented" methodology, we might consider a tool to aid in tracking progress, but with what we currently have invested in our present method, we'd probably feed at a minimum the short feature descriptions and time data to another system, unless someone has developed a module for Redmine that does what we want it to, or if it became really important to us, we might create the Redmine module ourselves to avoid any nasty integration headaches that might concern us.
If you discover a bug, I can't think of any good reason not to enter it into the bug tracking system, whether you fix it or not. That's what the bug tracking system is for, after all.
In some cases it might make more sense to report it to a QA person who has more experience dealing with the system, but in any case the bug should be tracked.
It's possible that there might be some reason, valid or not, that developers shouldn't be entering bugs. One possible reason might be that the bug tracking system is visible to outsiders, and having too many reported bugs looks bad. That's a very bad reason, which should be addressed in some other way that still allows bugs to be tracked. Ask your boss.
(Of course if there's a bug in code that you're still working on, and it doesn't show up in anything that's been released, there's no need to track it in the system, though a TODO comment in the source code may be a good idea. To take an extreme case, "This code won't compile because I haven't yet typed the semicolon at the end of this line" is not a reportable bug.)
As for why other developers don't enter bugs, you'll need to ask them. They probably should.
Best Answer
The only thing that can adequately answer this is your organization's process. If this situation isn't defined, it should be defined so that it is consistent every time it happens.
I'd recommend reopening the old one and adding new information to it as appropriate. From a measurements/metrics perspective, this would probably be the least harmful - the new thing is not a new defect or enhancement, but rather revisiting an old one. There should be some state for incoming change requests that indicates it needs to be reviewed by whoever the responsible party is. By changing the state back to this, they can see the history (the fact it was deferred once before) but also the new information easily.