Counter-example, and thus why I think this should be an IDE feature:
I have a function set_wifi_state(config: RadioConfig). I realise I've fouled up my design because I forgot about the Zigbee and Bluetooth radios, and this function should be split into two: set_radio_state(config: RadioConfig) and set_wifi_state(config: WifiConfig), but the two enums have variants with the same name.
With the current world, the moment I change set_wifi_state to take a WifiConfig, all calls to set_wifi_state fail to compile. I can now look at each one, and determine the correct outcome: should set_wifi_state(RadioConfig::Disabled) in each location be set_wifi_state(WifiConfig::Disabled) or set_radio_state(RadioConfig::Disabled)?
With your suggested change, all of the calls to set_wifi_state(Disabled) are ambiguous; did I mean set_wifi_state(WifiConfig::Disabled), or did I mean set_radio_state(RadioState::Disabled)? The compiler will assume the former - which is wrong if it really was meant to be the latter.
I can't have this ambiguity in today's Rust; if I'd written use RadioConfig::* to make set_wifi_state(Disabled) work, then it fails to compile as I'd expected. If I add use WifiConfig::*, then Disabled is ambiguous, and Rust complains.
With your change, the compiler has an unambiguous and wrong resolution to the ambiguity I've introduced by fixing my design fault - if, in my earlier faulty design, I'd written set_wifi_state(Disabled), where the new design wants it to be set_radio_state(Disabled), the compiler happily adds bugs to my code, because it re-infers Disabled to be WifiConfig::Disabled, where I really, really meant RadioConfig::Disabled.
This is why I think this should be IDE functionality - you want one thing that can add the use Enum::*; statement for you, and thus make the code much shorter while keeping it clear, and another that hides the Enum:: prefix in Enum::Variant for people who prefer the code to look shorter.