Incomplete item handling in sprint

I don't know exactly what you mean by "victimizing" a Product Backlog Item, but if the concern is that the team may or may not complete it because of uncertainty, that usually isn't a problem.

The commitment is to the Sprint Goal. Although there may be a set of Product Backlog Items most closely associated with that Sprint Goal, the team doesn't commit to Product Backlog Items. If the team is concerned that they will be unable to achieve the Sprint Goal, that warrants discussion with the Product Owner to ensure that the Sprint is optimized for the value that can be delivered. However, as long as the Sprint Goal is achieved, the inability to complete a given Product Backlog Item is generally irrelevant.

With respect to unfinished work, the Scrum Guide does say this:

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

To me, the most obvious answer is that you wouldn't go through the overhead of creating a new Product Backlog Item. Of course, if you learn that the work is no longer necessary or is no longer relevant, you could remove it. But otherwise the act of destroying or removing and then creating a new Product Backlog Item is generally unnecessary. The Product Owner can determine how valuable it is to work on compared to every other item in the Product Backlog, including recent feedback from the Sprint Review, and order it appropriately.

Whenever there is a PBI which is about to get victimized due to uncertain conditions in a sprint, is it advised in scrum to use the same story in upcoming sprint or a new story needs to created in order to continue from where it ended by marking the incomplete item as done from previous sprint?

A user story is a placeholder for a conversation about a possible requirement. Those who believe such conversations are unnecessary are likely to fall victim to the uncertainty you mention. From what you describe, the need for the conversation is still there, because the associated work is still valuable and has not yet been Done. It would therefore remain on the Product Backlog where it can be planned into a future Sprint.

Its about teams comfortability of team in handling incomplete user story cases, its about Team charter that was established in due course of time. Either way

1. Continue or move the same story to next sprint

2. Move the story in product backlog for further refinement

3. Close the existing story, create a new user story with incomplete work.

Can be true depends on below situations

1. the amount of remaining task already known and its not going to change further

2. it needs further refinement by whole team, discussion with PO for more elaborate acceptance criteria or clarification from business required or cross team dependency found/impacted the delivery of user story

3. In case user story is big then can be split and deliver a part in this sprint, and then further in another sprint based on refinement and new user story will be created. This holds true in case partial delivery was done from upstream team and further dependency observed , then we can move ahead for now with current user story closure, with Jira update and create a new product backlog item for further refinement and consideration in future sprints based on upstream/downstream teams dependency.

 It also depends on some unviable impediment occurance, any risk mitigation plan implemetation once the risk occured.

marking the incomplete item as done

did the incomplete work created any usable increment that can be delivered ? why the DoD will be overridden here ?