Names are actually only one part of it, and I do agree that they can add useful information. I think it’s really re-using structs or enums to serve as unions which bothers me.
I know there’s a strong motivation to piggyback on existing language features for the sake of minimalism, and to imitate C, but C-style unions are not fundamentally similar to either structs nor enums. An attribute on a type should not radically change the way a type behaves, but #[repr(union)] would. The repr attribute is for changing the way a type is represented in memory, not for changing its behavior. If different semantics is the whole point (which it is), then I think it would be preferable to use in-language syntax for it, instead of abusing attributes (which, apart from macro-attributes like derive, are supposed to be “metadata-like”).
Field access is strongly connected on an intuitive level to the guarantee that the fields of a struct are disjoint: if I refer to mystruct.foo and mystruct.bar, I expect that they will access different memory, and overwriting one will not affect the other, etc. The borrow checker even allows taking simultaneous &mut borrows to separate fields of the same struct. Reusing the same syntax for a C-style union would violate the principle of least surprise: when I see mystruct.foo I would have to look up the type definition to know whether the access has struct-like or union-like behavior.
I could write a similar paragraph for the enum approach, e.g. the expectation is that a match will match exactly one variant, i.e. that variants are disjoint.
A different syntax, such as as, would be more appropriate, making it clear that the same thing is being accessed in different ways, as opposed to different things being accessed.
(This is only my own, individual opinion - don’t change the RFC just to appease me unless you actually agree or there’s a consensus for it.)