Hi Henrik. I like Jeff's comment (above?).
I worry as soon as you say 'participate'. That opens the tent too much. (Although as a coach, with people under guidance, I might allow it. if it helps and does not 'disrupt'.)
I agree that always excluding all others can be counter-productive. We should not assume that everyone is always afraid of 'the higher ups'. Or, at least, that the issue is always so important that everyone else MUST ALWAYS be excluded. There is (often enough) value in having chickens watching during the 15 mins. (And value sometimes in someone (the SM?) talking with the afterward.)
Still, we do well to remember MJ's quote in the first comment.
It's a balance. Jeff said it simply and quickly.
One of the concepts (not sure how explicit this has been made) is NOT to worry (much) about inputs and to focus on increasing outputs.
One can argue that the only real output (in software) is a software release.
But, for sprints we have settled on the concept that the stories (done-done) are the key output.
Hence, putting too much focus on tasks (which are sometimes wrong or incorrect or incomplete or unnecessary) ... would focus on input (to getting a story done) and NOT outputs.
I do agree that most beginning teams need tasks to, among other things, learn to work more tightly together. (Which might be contrary to how the tasks are used. Haha.) Still, tasks can be used that way. Collaboration is a key principle.
The impediment list is an action list for the SM to get right people (including himself) to get it done. As always, the usual improvement expected from each one is an increase in velocity, but it could be seen as increased happiness, higher quality, more business value, or in some other way.
The key principle is that the SM get the most important (small piece) impediment mitigated first. (Single piece continuous flow.)
It's hard to prioritize a list if you don't have a list.
I am ok that PB Refinement is NOT included in Scrum. But, I would suggest some mention of it, that something in that area is almost always necessary, but we will not prescribe in Scrum how and when to do it. There is already some mention; I might be happy with that.