IMO your starting point is biased. If the developers fail to fix the bugs, the project is doomed to fail, whether they track bugs using a proper bug tracking tool, post-its, stone carvings, or not at all. It's not the tool's fault if it is not used or misused. (That said, there are of course bad bug/issue trackers out there... I worked on a project using a totally inadequate tool for this job, so I think I know how bad it can be. But there are good ones too, which require minimal ceremony and overhead, allowing you to focus on the relevant information.)
If, however, the developers do care, and the project is larger than trivial in size, and there is more than a single developer on it, and there is some sort of management involved (all of which are pretty common in real-world projects), soon there will arise questions like:
- Which of the open bugs should be fixed first? (note: in a sane project, this should be decided by the product owner and/or management, NOT by a developer - for which they must be aware of all open bugs first of all!)
- How many open bugs we have, and of what severity?
- Which of these must be fixed before we are ready to release?
- How much time to plan for these fixes - often leading to: how much time it takes to fix a bug on average?
- how many bugs have been reported by clients in the last release?
- who did fix this-and-this bug, when, and what (code / configuration / data) changes did the fix involve?
- what bug fixes are included in the release we are just about to publish?
Can you answer such questions [update] repeatably, reliably and efficiently [/update] based on your post-it notes?
Yes, entering bug data into an issue tracker entails some overhead. However, it is more than compensated by the time and effort saved in looking up, and creating reports like the above, from the stored bug data.