Adding new items to the current Sprint

Long story short. What capacity should a Sprint be initially filled? 100% / 80% / 70% ?

100%, in so far as there ought to be 100% transparency over the work the Developers are doing.

That 100% ought to include contingency...work which can be negotiated out of scope if needed, while still allowing the Developers to meet their Sprint Goal commitment. How much contingency is needed will vary by Product or even by Sprint, depending upon the level of complexity and the unknowns being faced.

How to deal with items worked on from the Backlog? Should they be inserted in the current Sprint? If yes, how to manage then?

If new work is discovered which is necessary to meet the Sprint Goal, the Developers will revise the Sprint Backlog accordingly. It is a forecast of the work they believe they need to do to meet this commitment. Any other work may or may not be done this Sprint.

There are no best practices when working in a complex environment. What works for one team in their context may not work for another team, even if that other team is operating in the same context. What we can share are good practices that have worked and you can explore if those practices make sense in your context, adopt the ones that do, and then inspect how they may have helped the team.

When using time-based estimates, you are correct that you should leave some buffer. For example, Capers Jones has found that a team uses about 85% of their available capacity for work. I've had the chance to review data from a number of organizations, and I've found that to be on the high side, so I tend to use 70-75% for planning purposes. This means that a 40-hour-week is really 28-30 hours or an 8-hour-day is really 5.5-6 hours. Another way of looking at it is a task that the team estimates to be 5 hours will be about a day to complete. You may be able to collect historical data for your organization and teams to get more precise figures. Leaving between 15% and 30% of the team's total capacity for unplanned work is not only realistic, but a good practice.

Loading to 100% doesn't acknowledge the fact that there are unknowns. The total scope of work is unknown. Although we have refined the work to the point where we are comfortable accepting the remaining risk, we have to acknowledge that we may find additional work is needed to get the work to a state where it's deliverable. The total capacity is also an unknown. Although you know the people on the team and the hours that they work, the total capacity may change if they have to work on things unrelated to the product or take unplanned leave. Planning to less than 100% capacity can help address both of these situations.

It's not clear to me how a team can estimate work, load their Sprint to capacity, get that work done, and get other work done. There are likely many explanations for this. Perhaps they are significantly overestimating the work. Maybe they are working extra hours over the planned capacity to get things done. Understanding how the team is estimating the work and tracking their hours is key. I'd be worried about people working too many hours, especially too often - it's not a sustainable pace and leads to burnout.

The approach that I've found that works well in most situations is:

1. Craft an appropriate Sprint Goal. It's often helpful if the Product Owner comes to Sprint Planning with a good idea of what the Sprint Goal is, but the works with the team to refine it.
2. Select the Product Backlog Items necessary to complete the Sprint Goal, based on the current understanding of the Sprint Goal and the Product Backlog Items.
3. Check that the size of the Product Backlog Items is achievable. When using hours, the estimated effort to complete the Product Backlog Items should never exceed 85% of the forecast capacity, and ideally shouldn't exceed 75% of the forecast capacity. If it does, iterate on the Sprint Goal and selected Product Backlog Items.

Whether the team selects additional Product Backlog Items up to 85% or even 100% of the forecast capacity is up to them. Some teams I've worked with have found it helpful to pull up to the full capacity into the Sprint Backlog, knowing that they probably won't get to those Items. Being very clear about what should be worked on if there is capacity is helpful, though. Other teams prefer to keep their Sprint Backlog focused on only the necessary work until the time comes that they are able to start something new. However, one thing holds true: the Sprint Backlog promotes visibility and transparency into what the team is working on, so anything that the team pulls into the Sprint should be visible on the Sprint Backlog to any stakeholders who can view it.

As @Thomas said, here are some practices that have worked best for teams I have been associated.

Forget capacity based planning and focus on value based planning.  Craft a good Sprint Goal, fill the Sprint Backlog with items that will allow the satisfaction of the Sprint Goal.  If you have to work extra hours, you do.  If you get it done before the Sprint ends, pull in some smaller items from the Product Backlog or spend time doing things like refinement, code clean-up, or learning new technologies that might be useful to implement.  This is my favorite and go-to if I have a choice in the matter. 

If I have to use capacity based planning, I tend to look more at throughput and cycle time to plan capacity rather than time.  Time is difficult to predict when you may not have all of the information you need.  However, trailing metrics like throughput and cycle time are based upon actual history.  Look back at the average of how may items the team completed in past Sprints.  Use that to determine how many items they may be able to complete in current/future Sprints. Look at cycle time to see how long items take to go from "ready to work" to "done".  These metrics are easier to explain and easier to justify. I've also found them to be more reliable than hour based capacity.

If I have to use time based capacity planning, I advocate the 70% mark and make sure that EVERYONE inside and outside of the Scrum team understands that our capacity is based upon a lot of guesses (i.e. estimates).  I do not like to track actuals vs estimate because it just leads to a lot of confusion, frustration and anxiety over being judged based upon numbers that you weren't able to completely control. 

I like @Daniel's first practice also. If you need to talk about percentages in relation to sprint capacity, then the focus of your team (or even worse: stakeholders or management) tends to shift to throughput in stead of value. I only use velocity as a metric for the team itself, to reflect on how they work towards a sustainable pace.

That said, if team members consistently choose to work on PBI's that are not in the sprint, then there is maybe an issue with commitment to the sprint goal, or perhaps team members don't feel they have enough say or influence during sprint planning.

Lastly, if your team worked on items outside of the sprint (and they are 'done'), at least mention them during the review. If they slip under the radar then your transparency is gone. Stakeholders should have an understanding of what the team works on, in general terms. And spend some time with the team to discuss why this happens, for example during the retrospective.