While this proposal mixes in some things that may divert attention, there is a notable asymmetry between struct and enum: When I get a value of some inferred type (e.g. a function return value) I can readily access the fields of a struct but I cannot readily destructure an enum.
The use diversion only enters this discussion because today it is necessary to fully qualify the variant names in if let, let else and match, which typically is shortened by importing the name of the enum.
However, I agree with the OP that there is no additional information or value in this precise naming, at least with the type system features we have today. When I have a value of type T in hand, its variants can only be the variants of T — there are no ambiguities.
My syntax proposal would thus be to only add _::Enabled(x) pattern syntax — which reminded me that this has been discussed previously.
The above argument changes markedly if Rust were to ever add union types (i.e. a type A | B that can be either an A or a B). In that case, it would be necessary to disambiguate variant names in patterns.
This is not to be confused with sum types (which may use the same notation) which need to distinguish both sides of A | A and therefore need notation for left/right in any case.