Reopen bug, Task, User Story is a good practice?

I don't see a right or wrong answer here - it depends on the tooling and the team's preferences. Barring any other strong arguments one way or the other, I'd leave it up to the team.

However, what to do with the representation of the bug and the work needed to fix it, I'd instead focus on the defect itself. Why is the defect recurring? What can be done to detect it earlier and prevent recurrence? Introducing defects into the product and having to fix them can get costly over time. Tracking them adds to the cost. How can the cost of defects be reduced?

Overall when Re-opening any PBI is a good practice???

Wouldn't it be a better practice to improve the Definition of Done, so these quality problems do not recur at all?

Opening new bug ensures that a new work or rework is treated as a first-class tracking item. In particular, it prevents rework (whether from bugs or iterative development) from being buried as invisible work inside reopened tickets, or from inheriting legacy time/effort estimates that don't apply to the current 

Opening new tickets ensures that all new work or rework is treated as a first-class tracking item. In particular, it prevents rework (whether from bugs or iterative development) from being buried as invisible work inside reopened tickets, or from inheriting legacy time/effort estimates that don't apply to the current work required.

For bugs 

If you have the code checkins within your tracking software, it could be wise to reopen it to have the checkins together when it is the same reason. For sure you can link the tickets which also helps, having the commits together helps even more.

For stories

What are reasons for reopening? Founding a bug - create a bug and check the test cases or why this bug came around. Is something missing then the acceptance criteria were not ok. Is something "additional" create a new story.

For tasks 

It highly depends what you use tasks for. 

All in all, I think there is not a golden rule, not even for bugs. 

Simple thing, bug should be resolved as soon as possible. if it is necessary to re-open same bug again in next sprint then you should do it as soon as possible. But you should find a root cause also to know the reasons. Some bugs are high priority and should be resolved as soon as possible on production. You can improve some practices in your team like TDD, Pair Programming, Better Code Review, Sonar Qube Analysis etc. to maintain the quality of code. 

While I agree with much already said, if the question is specifically around re-opening items closed from previous sprints, my advice would be not to re-open, but to create a new PBI.

A key pillar of empiricism is transparency, which involves the thoroughness of data and the accuracy of information radiation.   Re-opening previously closed items, even if the issue is around the same defect, may obscure the goal of transparency.   It may not be apparent at first glance how many times the defect has recurred if the item is re-opened, but if there are 3 similar defects all linked to one another representing 3 separate events where the defect occurred, the interpretation of data is much clearer.



Of course, there needs to be discussion on why the issue was closed in the first place, why it keeps recurring, and what the team can do going forward to reduce the likelihood of it happening again (i.e. - modify DoD).