Assuming its already-tested (and particularly if released) code absolutely.
There are a number of reasons for this:
Memory - The system is really unlikely to forget the bug, any given developer may.
Metrics - The number of bugs found, closed and the time taken can be good easy-to-capture metrics to tell you how the quality of your code is progressing
Urgency - It might seem like the most important thing in the world to the developer, however the time spent fixing this issue may be better spent on something that the end users want first (see also memory).
Duplication - Maybe it's already been spotted and is under examination / fix by someone else. Alternatively maybe it has fallen foul of the urgency rule and been put off. Of course the fact that you've found it again doesn't just mean that it shouldn't be done, it might mean that (as it keeps coming up) that is is now more urgent to fix.
Root cause analysis - The easiest bug to fix is the one that was never there. It may be that the team should be looking at this bug to find out how it came to be. This is definativley not to punish the one responsible (that never helps) but to find out how the situation can be avoided in the future.
Wider impact analysis - The cheapest bug to find is the one you knew about before you found it. By looking at this bug (particularly after doing root cause analysis) it may quickly become clear that this problem could exist in other places in the code. As a result the team can choose to go find it before it raises its ugly head at a more embarrassing moment.
The amount of time that is spent on these (if any) is largely dependent on the maturity and quality level of the code. Root cause analysis is likely to be overkill for a tiny team working on demonstration code, but a large team on business critical development probably need to learn the lessons effectively and efficiently.
From experience there are two broad reasons that developers avoid using the tool:
- The bug handling tool and/or process is perceived as too heavyweight for the development
- The developers find the mental challenge of fixing the bug more interesting than the stuff they are currently working on.
Item 1 implies that a better/simpler system may be required; or alternatively a more compelling justification of the existing system might be in order.
Item 2 should be a useful warning sign to the development lead about current task allocations.