I've been reviewing Jim Shore and chromatic's upcoming Agile book, and I especially like the "No Bugs" section here: http://jimshore.textdriven.com/Agile-Book/no_bugs.html
Large, dusty bug databases abound. Some teams have a process where this is unavoidable. Some teams use a bug database as a roadmap *shudder*.
Personally, I believer that a "low priority bug" doesn't exist. If it's a bug, why would you ever think of not fixing it? If a product manager decides that the current behavior of the system is acceptable for the time being, then why would you call it a bug? You may find the behavior of the system undesirable, but ultimately, it's the product owner's call what is desirable or not. Maybe he agrees it's undesirable, but there are other things more undesirable (like the complete absence of several large stories).
In my experience, poor management leads to a code-and-fix culture - working off a bug list. It's "easy" if there is just a running list of bugs. The team stays busy, and you can track work (kind of). What is hard is to lay out a prioritized road map and manage the growth of the product. Managing the product is actual work.
Many things can contribute to a low bug count: proper roadmap planning, good developers, automated tests, good software design, etc. I think the average life of a bug is also very important for the team culture.
To drive a culture of "no bugs", bugs cannot be allowed to live long. If a bug is announced, and nothing happens, the team accepts that the bug is there, and they will fix it "when they get to it". If someone stops and immediately addresses the bug, then the team knows that bugs are not acceptable. From a management perspective, I give bugs top priority. If there is a bug on our wall (red index card), it has top priority - no questions. The bug is not allowed to live. This is key for driving a "no bugs" team culture.