I think this is still in the stage of "vague ideas in our minds".
@Aloso the problem is the interaction with other pattern-matching features such as auto-deref. When x: &!, we might not want match x {} to work.
The reason is that match x { y => ... } is supposed to be equivalent to { let y = x; ... }, but then it would be odd if for x: &!, we consider that match arm unreachable (and consider it UB to ever get there with unsafe code!), without doing the same with let.
What is particularly bad about match x {} is that there is something here that deref's x, checks its discriminant, and then declares UB because there can be no valid discriminant -- but there is no code that actually does that. That should be some way to "point at" the thing that causes the discriminant to be loaded. Hence the proposal to allow match x { &! /* no code */ }. Now there is a match arm to point at that determines that there is no possible discriminant, and there is an & pattern that explicitly dereferences the reference.
Even with that proposal, let Ok(x) = r is legal; we just automatically desugar it to let x = match r { Ok(x) => x, Err(!) }. So, we can separate the discussion of "how do matches on uninhabited types behave" from "how much do we do implicitly in that area", because we have some explicit syntax for uninhabited matching and then, orthogonally, can implicitly desugar things to add that syntax without people having to write it.