I don't find the syntax weird, I think it's perfectly cromulent with the existing capabilities. To wit, pattern matching in `let` has always been possible:

    let (x, y) = (1, 2);

...But only for patterns that can never fail. For enums, not all patterns are irrefutable:

    let Some(x) = Some(42); // error, Rust can't tell that RHS isn't `None`

Note that some languages with pattern matching do allow the above, e.g. OCaml does, and just panics if the match doesn't succeed (so equivalent to `let x = Some(42).unwrap()` in Rust). But Rust favors exhaustive pattern matching, so that wasn't a good fit.

The way that Rust solves this is via `if`-style constructs. So you already have `if let`:

    if let Some(x) = Some(42) {
        // `x` exists in here
    }

This produces an inner scope where the contents of the enum are bound. And you can use `else` here as well:

    if let Some(x) = Some(42) {
        // `x` exists in here
    } else {
        // branch where `x` doesn't exist
    }

So the `let else` syntax feels like a natural continuation to me:

    let Some(x) = Some(42) else {
        // branch where `x` doesn't exist
    }
    // `x` exists here

This reduces the nesting required in several common cases of using enums, which makes code easier to read. (Of course, the interesting thing is that since `x` exists in the outer scope, the compiler requires the inner scope to never reach the outer scope (it must "diverge", by returning or panicking or infinite looping or whatever), which is an extra restriction above what a normal `if else` requires.)