Sprint Review - Acceptance of the User Story by Product Owner

PO can accept the user story as DONE anytime during the sprint timebox once the user story meets Definition of Done

The Scrum Guide doesn't talk very much about accepting work as Done. The only place where it does is in the context of cancelling a Sprint, where a Product Owner can accept part of the work, if it's potentially releasable.

I'd agree with the general sentiments of your statement, but not necessarily all of the details. I'm not sure it makes sense for a Product Owner to accept a User Story (or a Product Backlog Item in any format), but rather an Increment. The Development Team can produce an Increment at any point in the Sprint, as long as there is one completed as an input into the Sprint Review. Perhaps the team will product an Increment after getting each Product Backlog Item to Done, but this isn't required.

Stakeholder must present in the Sprint review for feedback

The Scrum Guide states that the attendees of the Sprint Review are the Scrum Team (Product Owner, Scrum Master, and Development Team) and "key stakeholders invited by the Product Owner".

I can definitely see advantages in having some external (to the Scrum Team, not necessarily to the organization) stakeholders present. However, as long as the objectives of the Sprint Review can be met, I don't believe that there is any requirement for the Product Owner to invite anyone else.

My understanding of Sprint review is more than a demo where the PO invites the Stakeholders and the development team will walk through the DONE work of the sprint and the stakeholders will be given time to explore the increment and then scrum team will go through product backlog if any changes or prioritization is required in accordance to the product vision. 

I'd agree with most of this. The Scrum Guide identifies a few other elements of the Sprint Review, such as reviewing work that is not Done, the Development Team discussing what went well / what didn't go well in the Sprint, and review of timeline or budget or marketplace for future releases. The important thing to take away is that the Sprint Review is far more than a demo, but often includes a demonstration of Done work.

Looking at the Scrum Guide 

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

• The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;

• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);

• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

Demonstration of the "Done" items is only a part of the Review meeting, but from my experience this is the most common understanding of the Review meeting.

Product Owner and Development Team should work together through Sprint on the PBIs and create a feedback loop for each in order to make sure that they work on things and bring the most value with the Product Increment at he end of the Spring. So all things that lead to not achieving "Done" with some PBIs should be discussed during Sprint.

Like @Thomas I agree your statements for the most part.  His statements about stakeholder involvement in the Review are very much like my own. For example, if the Sprint Goal resulted in an increment of value to the development team in order for them to continue work that will provide value to the end user, there really is no value in having an end user at the Review.

PO can accept the user story as DONE anytime during the sprint timebox once the user story meets Definition of Done

As @Thomas points out the only place in the Scrum Guide that acceptance by the PO is mentioned is in relation to canceling of a Sprint. The word accept is only found 3 times in the Scrum Guide. Search it to see where and how it is used. In all other places completion is based on meeting the Definition of Done which is something that the entire Scrum Team understands to mean completion. As such, the PO doesn't accept, the entire Scrum Team accepts when they agree that the Definition of Done has been met.

I applaud your questioning of the blog article. It shows you have a good understanding of the Scrum Guide and the value that all of the described pieces.  

PO can accept the user story as DONE anytime during the sprint timebox once the user story meets Definition of Done

The only thing a PO can accept is a "done" increment of release quality. That doesn't necessarily correspond to a particular item such as a user story. Unless they arrange otherwise with the Product Owner, the Development Team are under no obligation to ensure that each completed Product Backlog item is discretely releasable.

If the PO doesn't accept stories during the Sprint, how can they talk intelligently about what has been completed i.e. 'DONE' and what has not been 'DONE' during the Sprint Review? Seems to me, although not specifically stated in the scrum guide, it is necessary for the PO to review a story for completeness and accept it during the sprint.

If you read the Scrum Guide section where it describes the Definition of Done(DoD), you will see that the purpose of the DoD is to allow everyone to know at the same time when something is "Done".  This alleviates the need for an single individual to "accept" anything.  The agreement is that if the work meets the DoD, it is done. And since the entire Scrum Team has agreed on the DoD, there is an implied acceptance by all for anyting meeting that definition.

As for how does a PO intelligently talk about what is done, the PO is the one that has educated the Development Team on the problem that needs to be solved.  The PO has participated in the creation of and agreed to the definition of what done means.  So, they should be able to intelligently discuss anything that has satisified the definition without having to formally say "it is correct". Just as they should be able to intelligently discuss what hasn't met the definition of done.  They will be able to intelligently discuss everything because they have been involved at all times in the efforts to understand and satisfy the problems represented in the Product Backlog. If the Scrum Team is truly practicing transparency, then there should not be anything that anyone on the team doesn't know at any point in time. 

 Seems to me, although not specifically stated in the scrum guide, it is necessary for the PO to review a story for completeness and accept it during the sprint.

For me this statement emphasizes that the Product Owner does not have trust in the Development Team to deliver what they have said they will based on the common understanding that all have achieved during refinement of the stories being addressed.  In Sprint Planning(from the Scrum Guide section describing Sprint planning) "the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.".  Why does anyone have to approve the work that others in the Scrum Team are doing?