Statically checked pattern matching validates that the provided patterns cover all possible values the variable could have (the whole space of the variables declared/inferred type). So the actual runtime value is not necessary: if the match is exhaustive, there is no possible value that could be taken at runtime that would result in no match.
Why would you care about selecting the branch in compile time? We're talking about language features semantically equivalent to pattern matching, and, turns out, there are none. As for the importance of the exhaustion check, see the billion-dollar mistake.
Your solution with type and value checks in an if ladder was called "dynamic typing" exactly for this reason - you select paths dynamically in the runtime without any static checks on soundness of this selection.
> Why would you care about selecting the branch in compile time?
I wouldn't. Pattern matching is primarly a conditional, that's why I focused
on if-else.
> We're talking about language features semantically equivalent to pattern matching, and, turns out, there are none.
Why would you think that pattern matching revolves around compile-time
guarantees? It does not. It's primarly a conditional, everything else is an
optional, additional effect. You can have pattern matching in dynamically
typed languages (Lisp, Erlang).