Team struggles with Refinements/Estimations

Having a Developers Refinement -> Refinement only for Developers where they can discuss the Stories, explain it to each other (Onboarding Aspect) and fill it with more necessary informations or post questions in the comments for the Product Owner to resolve. Until the next Refinement, the Stories should be in perfect condition to put Story Points on them.

Why impede refinement in such a way? Why isn't the Product Owner immediately on hand in every refinement session to explain the work on the Product Backlog?

- Estimating in Hours, calculating the Developers with 6h productive hrs per day so there is a "puffer" in case of Meetings and problems coming up, also we are not planning exactly the calculated hrs of the Sprint and leave a puffer there too.

I think you mean a buffer. Why obfuscate matters this way? All a buffer does is to reduce the transparency you have over the work that actually happens.

- With the hours, we were adding a "risk level" to the Stories -> Level 1 through 5 that goes from 1 -> low risk and is probably easy to solve without complications to 5-> needs a lot of investigations and problems are most likely to appear.

You've seen the results of doing so. The work is not Ready for Sprint Planning and the risk is then deferred onto the Sprint itself, within which commitments have been made, and which are consequently unlikely to be met.

Refinement is the art and science of making work Ready for Sprint Planning, such that the Developers are confident that it can be Done in a Sprint. Their commitment to do so may then be made with confidence.

My first step would be to stop using story points. But you don't have to take my word for it. Check out PSTs Ryan Ripley and Todd Millers videos (1, 2, 3) on the subject. Or maybe check out what Ron Jeffries, who is attributed as a creator of story points, has to say about them. I'm in the camp that, although useful in some cases, story points often cause more problems than they solve. This is compounded by the fact that you need to teach and align across team members what different values actually mean. It's a lot of wasted effort.

Instead, I'd do two things:

1. Focus on refinement. Work on decomposing each Product Backlog Item into the smallest change that makes sense. Work on figuring out what you are able to demonstrate or deliver in order to get feedback that can help you plan the next step. Make sure that what you are demonstrating or delivering is well-defined and understood by the team.
2. Capture actual values about how long it takes to go from start to Done. Use this information to calculate cycle time and throughput. You can use this information to figure out how much work you can do in a Sprint. Plus, the units of cycle time is usually hours. Capacity is also in hours. It's much easier to adjust for changes in capacity or accounting for overhead work since everything is measured in the same units of time.

Specifically on the subject of refinement, consider moving away from full-team refinement meetings for all refinement. In my experience, the best refinement happens with small groups focusing on understanding the problem and some high-level thinking about possible solutions. Full-team meetings are useful for synchronization and planning what needs to be refined and how to refine it, but far less useful for making progress in refining work.

If you dig deep into your refinement practices, you'll probably find a lot of opportunities to improve the understanding of the work and the technologies needed to deliver that work.