What's the best time to schedule the Sprint Review?

The right time is the best time for the team. Are they actually having difficulty self-organizing the best time for this? If so, then that's the problem to solve, rather than trying to address this specific case.

Some of your givens aren't necessarily correct.

The Review and Retrospective do not need to take place "on the last day of the Sprint". The Retrospective "concludes" the Sprint. However, there are no rules about where on the calendar these events fall. Your wording seems to suggest that you should hold the Review and the Retrospective on the same day, and that's not the only valid combination. You could hold the Review on one day and the Retrospective on the next, perhaps with the Planning on the same day as the Retrospective or not. Although I wouldn't have too much time between them, having the Review on a Wednesday morning, the Retrospective on Thursday morning, and the Planning on Thursday evening or Friday morning is just fine.

Unless you've had conversations with the team and key stakeholders, I would not make assumptions that the Retrospective - or any event, really - shouldn't be held late in the day. Although it's true that people may be more tired - physically and/or mentally - late in the day, the team may want to adjust their schedule so they can have it later in the day. There are ways to minimize the impact by ensuring a lighter work schedule early so the team can remain refreshed and energized throughout the day when it comes to the afternoon hours.

I'm not sure what you mean by "the work time after the Review isn't really accounted for". I've worked with teams that held a Review in the morning and their Retrospective and Planning the following day. I've also worked with teams that held a Review in the morning and the Retrospective in the mid-afternoon. They used the time after the Review for things like refinement of the feedback that came out in the review (sometimes so they could start it in the upcoming Sprint), taking care of company overhead activities, or even did their best to schedule appointments and time off here because it's the least impactful to the team. There are plenty of ways to make use of time that aren't necessarily doing Sprint Backlog work.

The right time to schedule the events is what works for the people who need to be there. Choosing a Review time that doesn't work for your key stakeholders would cripple the event. So planning your Retrospective and Planning, which only require the team, based on that would work. Then the team can look at the calendar and figure out the best ways to use the time that may exist between the events.

Thank you very much Thomas for your response.

I completely agree when you say, "The right time to schedule the events is what works for the people who need to be there," but on the other hand, the guide specifies that "The Sprint is a container for all other events" and "All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happens within Sprints."

In my opinion, scheduling the Sprint-1 retrospective on the same day as the Sprint Planning for Sprint S does not adhere to what the guide specifies.

Currently, we have the review in the late morning and the retrospective in the mid-afternoon. Between the Review and the retrospective, developers finalize the last things and can validate some tickets (which will not be presented at a future Review), as the sprint is not finished. 

This is what bothers me.

Upon reflection... the guide does not specify that the start of a sprint necessarily occurs at the first hour of the day, nor does it necessarily end at the last working hour of the day.
Indeed, we could very well have a sprint that starts and ends at noon every two weeks.

Thanks again Thomas