In addition to Thomas' answer, a bug report that leads to a code change is just as much a part of your code's history as the requirements specifications, architecture documents, customer change requests, etc.
Another way to look at it - would you delete the requirements documentation after having successfully implemented a feature in the code, or would you leave these so that you (or other developers in future) have some chance at being able to discover why the code exists and are able to validate that the code actually does what its users/stakeholders have asked for?
Ideally a bug report will contain a lot of valuable information for future developers digging into the code to learn when and why a particular line might have changed. For example - Who reported the bug and when; The circumstances around the bug; How to reproduce it; Root-cause analysis; Some discussion with stakeholders on the validity of the bug; along with any other potentially relevant context.
As far as standard practice is concerned, I would also expect developers raising a pull/merge request for a bug to explicitly reference the ID of the bug in their commit message(s) and/or the PR itself so that the source control history also provides breadcrumbs to the bug database.
Future developers having the source/commit history can use this to relate individual lines of code back to the original thought processes and reasoning behind why that code had been changed by following breadcrumbs like a Bug ID.
Otherwise if the bug report is deleted then all the valuable investigation, discussion, analysis and reasoning is lost along with it.