It's not anything specific to arrays, it's just how type inference works. Here's another example:

    let mut x = HashMap::new();
    x.insert(1, 2);

Note that nowhere did we need to specify the concrete type of the HashMap; the compiler sees that you eventually insert numbers into the map so it uses that information to fill in the generic type parameters for the key and value.

I think the one here is legit (perhaps more realistic would be where you're passing the new array to an actual function that requires a certain array length).

People always complain about Rust's type system being verbose- well, this makes it less verbose. It knows what you need from the function call, so it doesn't make you say it. And as an added benefit, if the required type ever changes in a way that can still be generated by the provided code (eg. the function you're passing to needs a different length), you won't need to update any explicit type annotations at the call-site.

If that's ever undesirable - you want to be very precise about your code - well, then you can do that too by specifying the generic parameters explicitly.

  let numbers = [0, 1, 2];
  let doubled = numbers.map(|x| x * 2);

You wouldn't want to have to explicitly type out the length of the second array.

A few use cases:

    let foobar = Default::default();
    do_something_with(foobar); // where do_something_with takes a FooBar param

One I often use in unit tests:

    fn generate_ids<const N: usize>() -> [Id; N] { ... }

    let [id_button, id_label, id_thing, id_other_thing] = generate_ids();

(before const generics were stabilized, the above code instead had multiple utility functions, eg generate_2_ids, generate_3_ids, etc)

You general type inference, or inferring the array length? The latter follows from the former, so it would be kind of a weird hole in the language if type inference worked everywhere except array lengths.