If we were to assume that the average velocity of the Scrum Team was 50 Story Points over some recent number of Sprints (usually the last 3-5 Sprints, in my experience), then you could apply Yesterday's Weather and plan on your next Sprint having a velocity of close to 50 Story Points. However, this does make some key assumptions. One assumption is that the capacity of the previous Sprints and the upcoming Sprint are close. Another assumption is that process improvement experiments are being neglected in velocity calculations. However, it's a fairly quick and easy calculation that the team can do on-the-fly to figure out if they are planning on a reasonable amount of work for a Sprint.
As far as reserving additional time for unpredictable work, empiricism also comes into play. Empiricism is about making decisions based on knowledge and observations obtained in the past. How often does the team take on unplanned work in the course of the Sprint? What is the typical size or effort associated with this unplanned work? How tolerant is the organization of deviations from the planned work? The answers to these questions will determine if you should load your Sprint to capacity. I always prefer to leave a buffer of about 20-30% to account for unplanned work and unplanned absences in the team. If I obtained a velocity of 50 Story Points by applying Yesterday's Weather, I'd plan on aligning my Sprint Goal to no more than about 35-40 Story Points. Work to fill the remaining capacity could be identified at Sprint Planning, understanding that the work associated with the Sprint Goal is the most important to have complete by the Sprint Review.
I don't necessarily agree that filling a Sprint to maximum capacity means that the team has a 50% probability of completing all the work. It's neglecting the likelihood of changes to capacity, the necessary variability in estimates, and the discovery of more or less work as the Sprint goes on, among other things. I'm not sure if I could quantify the probability of work completion beyond "likely" that the team will perform similar to the recent past. A process improvement could lead to improved performance or perhaps have a negative effect. A team member could need an unplanned 2 or 3 days out of work to deal with a life event. Perhaps some tooling or infrastructure issue prevents one or more people from carrying out their work. It's hard to quantify these, but more details about the organization will help understand what has happened in the past.
I'd also point out that all of this is built around the output of work instead of helping customers and users achieving the desired outcome. The Sprint's purpose is not to complete a certain number of Story Points but to deliver value to the end-user. Story Points aren't a measure of value. Completing a single 2 or 3 Story Point unit of work could be immensely valuable and entirely worth funding the entire Sprint. Focusing on creating and achieving a valuable Sprint Goal, ensuring that the work needed to achieve that goal can likely be done within the Sprint. Focusing the team's effort on the goal will have bigger payoffs in the long run than counting the delivery of Story Points.
