Can a User story marked to be Done before Sprint closure

Personally, I have never advocated for an Estimated Time of Arrival(ETA).  The implied ETA is by the end of the Sprint.  That is the commitment that the Developers make by pulling an item into the Sprint. Anything more specific has never been needed.

As for when to mark something as "done" that is something I leave up to the Developers.  They are the ones doing the work and they are the ones that are expected to meet the Definition of Done.  However, waiting until the last day does seem like they are not willing to make their work transparent.  I would also think that it would make it more difficult for the Developers to understand what work is left to complete during the Sprint.  But again, this is something that occurs in the Sprint Backlog and the Developers own that backlog.  So they should be allowed to manage it as they choose. 

1. If the User story updated with an ETA, then it gives us an indication that this can be completed within a sprint duration. 

The Scrum Guide says:

"Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities"

If they receive that degree of transparency only upon a so-called "ETA" being determined during a Sprint, what does that suggest about the efficacy of Product Backlog refinement?

2. If the User story is meeting all the acceptance criteria, then why should we wait until the last day of the sprint review & retro meeting. Why can't we close it as soon as it is developed.

The Scrum Guide says:

"The moment a Product Backlog item meets the Definition of Done, an Increment is born."

You could think of acceptance criteria as representing a certain level of Done. Other work may or may not yet need to be integrated into the Increment.

Regardless, there is no value to be found in "closing" a Product Backlog item. The value is only to be found in releasing it, such that it can then be used immediately by stakeholders and empirically validated.

1. why do we need to have ETA for the User story

I'm not sure what you mean by "ETA for the user story".

If you mean an estimate, Scrum does not require estimating or sizing work. Some teams find such practices helpful. Others find flow metrics - such as throughput and cycle time - more useful than estimating Product Backlog Items.

It is expected that the Scrum Team collaborates to create a Sprint Goal that is achievable by the end of the Sprint timebox and this Sprint Goal becomes the commitment by the Developers. How that is done is not specified and is up to each team.

2. why can't we mark the User day DONE on the last day of the sprint (even all the tasks are completed)

If the work is done, why wouldn't you indicate that it is done? Visibility and transparency are key elements of Scrum. I would look at your Definition of Done and say that work can be marked as Done whenever it meets the Definition of Done, regardless of when in the Sprint it achieves that state. However, depending on your tooling, there may be other considerations.

Thank you all for the responses and valuable insights. 

My question for asking the Estimation time of Arrival [ETA] was due to few scenarios which I encountered in the past.  

1. There were inter dependent PBIs within the sprint backlog [Ideally it should not be, but this was inevitable due to technical challenges]. By not having the PBIs ETA, the other developer was unable to predict the integration of his/her PBI. 

2. There were dependencies with other product team where one of my product teams is dependent on them on completing few PBIs. [Ideally we shouldn't have taken the PBI in our sprint backlog, however the goal for the sprint can be achieved only when this PBI is implemented but that was having dependency with other Product team]

Reason behind asking "why can't we mark the User story DONE on the last day of the sprint (even all the tasks are completed)" - PO was not interested in taking the demo from the team as soon as the PBI is completed. PO wanted to use the Review & Retro ceremony to mark all the PBIs to Done in the system. There were situations when PO was not available on the last of the sprint and demo was not completed due to which most of the PBIs were not closed in the tool because it was not meeting the DOD.

DOD for my product team is:

- Meeting Acceptance criteria

- Code Reviews to be done

- No open bugs

- Demo to be completed with PO. 

Please advise if there are any better ways to handle these practical situations.

For one, I'd remove the "Demo" from the Definition of Done.  In my opinion, that has nothing to do with having something ready to be released.  The Product Owner should be involved during the Sprint to know what is being done and trust that the Developers are delivering a solution for the situation that the entire team has discussed, refined and considered to be ready to work in a Sprint.  Including something like "demo to Product Owner" in the Definition of Done indicates a lack of trust in my view.

About your ETA situation.  I would say that you are pulling items into a Sprint before they can be completed by the Developers if there are still external dependencies that have to be completed.  The Developers are setting themselves up to fail by doing so.  All of those external dependencies should be identified during the refinement of the stories and every effort should be made to work with the other teams to complete their work before your team needs it.  These are impediments to your Developers ability to complete their work.  As Scrum Master, you are expected to help remove those impediments.  I do not mean that you have to do the work, but you should help your Developers learn how to eliminate them before they become an issue.