If we already use a bug tracking tool we are used to it. No need to learn something new.
The bug report contains more data inherently (environment, statuses etc.).
You can attach logs and screenshots.
An important source of information:
- Data on fixed bugs (important for example if the bug re-occurs and you want to know when it was fixed. Then the developer can find the fix in the source control and save some time).
- If you find a bug and search for duplicates, you might find that the bug was closed as 'won't fix', so no need to open it and thus save time to the system.
In case some teams are working in the same project. You want them to be aware of bugs that can influence them.
If you need to measure bugs (are there too many re-opens etc.).
Many bugs you spent time reporting will never be fixed.
A simple note is enough + adding the scenario to the (automated) regressions.
If you are working in Agile mode, and you find a bug in the stage of 'supporting the team', and the bug is closed immediately, it is the same as in a waterfall. When developers find a bug and fix it, they also don't report it.
It encourages verbal communication between teams (see #5 above)
In case of important information, it can be saved in FAQ page.
Requires a lot of time spent: writing, triages, explanations, reproducing, comments.
To my opinion, bugs in the development mode should be written down simply (not in a tracking system).
In case it is fixed in the same sprint - delete it. In case it is not fixed - properly report it.