Do you have any empirical evidence that the Scrum Teams you are working with are padding their estimates? If so, has this come up at a Sprint Retrospective? If it is happening, there are likely to be bigger issues, perhaps organizationally, that can be addressed.
Going to the Sprint Goal, the November 2020 Scrum Guide "communicates why the Sprint is valuable to stakeholders". A Sprint Goal that is "complete 70% of the most valuable items from the planned Sprint Backlog" does not meet the Sprint Goal criteria. If the Product Owner and/or the Developers are having problems crafting a Sprint Goal, this is a good opportunity for coaching. There are some good resources out there for defining Sprint Goals, and the addition of the Product Goal in the November 2020 Scrum Guide may help.
Once you step away from the Sprint Goal as a set of Product Backlog Items and defined as a valuable outcome for one or more stakeholders of the product, there are no rules for how many Product Backlog Items need to be completed to satisfy the Sprint Goal. In some cases, the Sprint Goal could be accomplished by completing a single small-sized Product Backlog Item.
I try to encourage the teams that I work with to ensure that the Sprint Goal's completion doesn't require completion of all of the Product Backlog Items. Exactly how much buffer to leave depends on the organization. If there are many interrupts and overhead, it could be as low as 50-60%. In other organizations, it could be as high as 75-80%. This is on top of leaving room in the Sprint for refinement and making process improvements, which also need to be considered in the Sprint Planning session.
In the end, the team should be asked and, generally expected, to deliver the Sprint Goal every Sprint. When the Sprint Goal is not met, that should result in a good discussion of what went wrong in the Sprint Retrospective and the necessary changes to increase the chances of success in future Sprints.