User story scope is reduced in current sprint. Should we re-estimate its points?

The Scrum Guide says:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.

If the Developers did not re-estimate the work remaining, would they then have a real-time picture of the work needed to meet the Sprint Goal?

I'm going to take a slightly different approach than Ian.

How do the Developers maintain their Sprint Backlog?

Sometimes, it's at the Product Backlog Item level. In your case, it sounds like user stories are used to represent at least some Product Backlog Items. If you are following Product Backlog Items without further subdivision, then perhaps it makes sense to revise the associated estimate and description to clarify the actual status of the Sprint work.

However, other times, the team decomposes the Product Backlog Items into smaller, more granular tasks tracked throughout the Sprint. In this approach, the tasks and their state form the "real-time picture of the work" performed throughout the Sprint, and updating these tasks is updating the Sprint Backlog. In this approach, you could discard the tasks considered out-of-scope now and put another item on the Product Backlog to represent anything needed in the future.

As long as the Sprint Backlog is maintained and gives stakeholders a clear and accurate picture of the state of the work being planned and executed by the Developers, the details of how the Sprint Backlog is managed are left to the discretion of the team. Perhaps you can even think of a third or fourth approach to maintaining the Sprint Backlog, which may or may not require reestimating the Product Backlog Item.

And for a 3rd approach I chime in.

What benefit does it provide to re-estimate the story?  You stated 

...estimated with highest points and now as scope is reduced, should we re-estimate the points again as now the story is remained with lesser amount of work only?

In the case of Story Points, they are a tool help a team determine the amount of effort needed based on the information you have at the time of the estimate.  Those estimates can help the team pull items from the Product Backlog into a Sprint Backlog in a manner that makes the team comfortable with their decisions.  It helps them identify a threshold at which they feel they have not over committed themselves.  Then work begins.

When work begins, you learn more information which could increase or decrease the complexity of the effort.  But since work is underway, does it really matter what the original estimate is?  What if you discover something on Tuesday that makes everyone think it is going to be easier and then on Thursday uncover more information that makes everyone question if they can actually complete the work before the end of the Sprint.  Does re-estimating everytime that new information is uncovered provide any real benefit or should they instead focus on accomplishing the goal of completing the effort?  To support @Ian Mitchell's comment, they should be constantly re-estimating in order to determine how much they can accomplish during a Sprint but is changing Story Points actually necessary? If the item is not completed during the Sprint and needs to be put back into the Product Backlog for future consideration then changing the Story Points might be a valid option.

Modifying the Story Point estimate during the Sprint is only useful if you incorrectly use Story Points as an indicator of velocity or to measure a team's output but that is another discussion that I'm not going to get into right now. 

Thanks very much Ian, Thomas and Daniel for providing your inputs. 

Yes Thomas, so the stories taken in sprint backlog are the PBI without any subdivision. As you explained further, I with my team follow this approach in our project that we take the full item from PB into sprint backlog and further divides into sub-tasks, thus if any of the task is remaining we carry forward to further sprint.

I got your point Daniel and make sense not to re-estimate the story as complexity or effort during work in progress can either be increased or decreased. As the whole team is transparent about each other’s work and well aware of what items/stories/tasks are completed/in-progress in the sprint, should it right to say in this case that if all the stories are completed before the sprint ends, then the estimated items from PB can be pulled in based on remaining effort?

should it right to say in this case that if all the stories are completed before the sprint ends, then the estimated items from PB can be pulled in based on remaining effort?

In my opinion, yes.  In fact I don't see any problem pulling in work from the Product Backlog during any Sprint as long as it does jeopordize the team's ability to meet and satisfy the Sprint Goal.  I had one team that would consistently craft their Sprint Backlog and Sprint Goal in a way that they knew would not require them to be engaged for their entire Sprint.  This allowed them to have time to deal with production issues and to do some investigations into new technologies or practices. As a self-managed team, I did what I could to help them with that practice. 

Thanks Daniel for providing more inputs. :)