Allow me to explain, then: structured pattern matching is (even by admission of PEPs 634-363) an extension of iterable unpacking. The use of '_' as a wildcard pattern is a sharp break in that extension. In the structured pattern matching proposal, '_' is special syntax (and not in any way less so than '?') but *only* in cases in match statements, not in iterable unpacking. It *already* isn't consistent with '_' in other languages, and we can't fix that without breaking uses of _ for gettext, not to mention other situations existing code uses '_' as something other than an assign-only variable.

Using '_' in structured pattern matching means any use of '_' becomes an extra burden -- you have to know whether it's a name or not based on the surrounding context. It makes all uses of '_' harder to parse, and it makes it easier to mistake one situation for another. Perhaps not terribly easy, but since there is _no_ confusion now, it's by definition *easier*. The use of something else, like '?', leaves existing uses of '_' unambiguous, and allows structured pattern matching and iterable unpacking to be thought of the same. It reduces the complexity of the language because it no longer uses the same syntax for disparate things.