I think we've fallen in the trap of assuming we all agree on the meaning of "scope".
In Python, that word is typically used to refer to a bunch of behaviors that go together. In particular, "the current scope" is where assignment creates new variables. (It is also linked to the semantics of "return" and "yield", and to "global" and "nonlocal".) The paper uses it in this sense.
The problem with using scopes *in this sense* for case blocks is that all assignments to variables inside a case block would create the new variable in the scope of that case block. But consider this example:
```
match arg:
case Point(x, y):
p = (x, y)
case (x, y):
p = (x, y)
case _:
raise TypeError
print(p)
```
There are no assignments to p outside the case blocks. Giving each case block a traditional "scope" would prevent the print(p) call outside the match statement from seeing the variable p. (Please don't argue that this should be refactored by putting the print call in a helper function.)
Now, of course we could change the language so that this all works. But it would require a lot of changes to the compiler, since it gives scopes a bundle of semantics that would have to be separated out.
We could also agree to keep the language the same and use "scope" with a different meaning (the meaning that you seem to want). But you can't blame the paper for using it in the way it is used, since that is the conventional usage of the term for Python.