At a technical level, bugs, features, it's all the same, a change request. Do you ever decide not to add a feature because it's not worth it? It's the same with bugs. The only difference between bugs and features is commercial - 'customers' pay for features, the 'company' pays for bug fixes, or something like that.
However, as with feature requests, every bug report needs a change tracking ticket. The ticket must be as easy to close as it is to open. That is the only way you will capture the data you need to make decisions.
Change requests should be closed as quickly as possible. The reason for this is open requests take time to analyze, clog up the system and add little value. You need to quick way to decide that you won't do it, and once that decision is made, close the ticket. You should aim to never discuss if an item should be open or closed more than once. One of the biggest problems I see it the reluctance of people to close a ticket "Will not fix", so they leave it open. If you ain't gong to fix it, be honest to everyone and just say "We ain't going to fix that, get over it."
Have both Priority and Severity in your ticket. The effect of the defect on the system is it's severity, sales and marketing set the priority.
Use a figure (say 20%) from the budget of feature requests/enhancements for fixing bugs. (i.e. if I do 10 days adding features, I do 2 days fixing bugs). Bugs are fixed in Priority order till the budget is spent. This gets around the commercial drive for features only development.
The cost of a defect is exponentially proportional to the time between insertion of the defect and fix (Or decision not to fix) of that defect. To prevent those niggle bugs costing disproportionate amounts of $ because you don't fix them, and refuse to close them, open tickets have their priority raised on a regular basis (Say 5 priority levels - once a month), and cannot be lowered. That way, you will be forced to deal with it within say 6-12 months.