Have you tried teaching them how to make estimates? I didn't see that in your list, and not everyone automatically "gets" how to do it.
I've encountered two main reasons for an unwillingness to make estimates: one was anxiety over being held to it, but the other was that they'd never done it before, so when I asked them "how long do you think that will take?" they answered honestly "I have no idea." When I pressed them, they said "Well I would just be guessing!" (Which might translate, in planning poker, to picking a card at random.)
So we talked about how an estimate is a guess, but it's an educated guess, and everybody understands that; and then I walked them roughly through the mental process I use to make estimates, and said of course they wouldn't be very good at it at first if they'd never done it before, but we would practice and they would get better at it. I also contextualized why estimates were important for us as a team to be able to do (building confidence in ourselves and trust with our stakeholders that we will be able to do what we say we will be able to do), and pointed out that learning to make estimates is also a good career development move. (If the folks who are resistant are deferring to "senior devs", this may be a good argument for them.)
I think the easiest way for people to start making estimates is in terms of ideal work days, ie, supposing that I could spend 100% of my time on this task without interruption, how long would it take me? Story points may be too abstract for people who are just learning this skill.
Re your QA people: I've also found that people are reluctant to participate in estimating tasks that they won't directly work on, eg people who work on one subsystem don't want to estimate work that is contained entirely within another subsystem. My solution has been to say "well you've seen how long it takes the other subsystem folks to do tasks like that, so give it your best guess that way." They're still reluctant, but at least I've given them a rubric to follow.
At this point I don't think there's anything left for you to do in the team process. I would try one or more of the following (in no particular order):
approach each reluctant dev individually in private, and ask from a position of curiosity, what is the issue they have with making estimates?
approach the reluctant devs' line managers (assuming that's not you?), and give feedback that they apparently need training in how to make estimates. (IE, don't get into "won't" and tantrums; focus on "don't seem to be able to do that task", therefore must need training)
approach the line managers, and make sure your expectations of dev responsibilities is consistent with theirs, esp. around estimation.