I asked some colleagues about what this may be happening, and they
mentioned that if a bug doesn't haven't that level of priority it is
very rare that the Bug gets developer attention, which indeed makes
Actually, if you ask me it does not. The more (used) levels of priority, the more information you have. If you effectively only have one priority, that's the same thing as having no priority at all.
And since you still have the same number of bugs to tackle, and the same amount of manhours in which to do it, it follows that some other heuristic will be used, possibly the null one - "first come, first served". And so you now have a bug priority metric, except that's the time of arrival and no longer under your control.
It can be a symptom of not enough resources being allocated to the bug fixing (there are some policies such as "No new features until the bugs are fixed" that can help there. Joel approves; understanding limits and consequences is a business decision).
In one project I worked, the incoming bugs were accumulated in a "no priority buffer" and every Monday we would review the bug list, estimate difficulty (a very rough estimate; more often than not we just put in, "Average") and sort them by available time. This did tend to bump down the list boring, uninteresting or thought-to-be-hard bugs; to offset that, supervisors and marketing had a certain number of credits per week that they could spend to bump the priority of favorite bugs, and were reimbursed for unsolved bugs (this set a limit on how much a developer-despised bug could be delayed).
It was also possible to merge, cancel and split bugs; I remember one module which was so hopelessly flawed that we sank some twenty or thirty bug reports into a single "rewrite this thing from scratch", which was then split in "clearly state the inputs and outputs of the wretched thing", "write tests to ensure inputs and outputs match the spec", and so on. The last item was "print the old code on recycled paper, bring it out on the lawn and set it on fire" (we did that, too. I remember how good it felt. We took turns on the eulogy; it was quite hilarious).
After some haggling, we had the week's to-do list, which was divided in "will do", "might do" and "can't do" that were bumped to next week. This is where some additional haggling came in: we had say fifty hours to allocate to bugs, and we were 95% sure to fix the first twenty. The management strongly wanted a twenty-first bug to be fixed and had no credits left; we would then offer to swap that bug with one on the "Will do" list, or someone would say "Get me off the FooBazFeature subteam for a couple of days and I'll do it", or we would say "We need more manpower".
The system satisfied no one, really, but this was believed (at least among the developers) to be a good sign.
Some additional negative patterns that turned up were the "Wishful Thinking" on the managers' part ("You stated bug 57212 requires eight hours. That is unacceptable. Make it four") and the "Debug by Fiat" ("Do whatever you want but these forty bugs must be fixed before the big demo next week. You cannot have more time, you cannot have more people"). Also the Boxer Syndrome ("I will work harder"), that tended to work very well for a short time, but usually led to a developer freaking out or leaving for greener pastures.