Scrum Guide
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

As the Sprint Backlog emerges across the Sprint, if the work needed is larger than what the team can produce, the Product Owner needs to be informed and the work might change

Scrum Guide
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. 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.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

The Sprint Review enables empiricism by providing an opportunity for the Scrum Team and the interested stakeholders to inspect the increment and adapt the backlog. The Sprint Review supports transparency because everyone can see what has been produced in the Sprint.
If only part of the Scrum team was present, there would be less transparency. The Scrum Team members who were not present lose the opportunity to directly hear the feedback provided during the review. Directly hearing from stakeholders increases their understanding of what the stakeholders want.
This answer covers the two parts of the question since it asks about how the Sprint Review event enables empiricism and what is the impact in case not the entire Scrum team attend it.

Acceptance criteria and User Stories are complementary techniques that help to capture customer's requirements, however, they are not part of Scrum.