This doesn't feel like an idiomatic use of enums to me; the individual methods on A and B are superfluous and could just as well be written inline in the switch. As you said, if it's interesting for A and B to both share the API individually and as a single abstraction, then a protocol makes much more sense.
Setting aside temporary limitations, I think it'd help to look at the fundamental difference between enums and protocols to help derive guidance about when each is ideal. For a protocol, the "cases" are always types with individual identity, and the protocol itself does not directly have a type identity. (Existential types exist, sure, but from a model perspective I think it makes sense to consider these structural types derivable from generic constraints rather than something fundamentally tied to protocols.) On the other hand, an enum is the reverse—the cases have no type identity, but the sum of them does. That suggests that enums are at least the best tool for generic abstract sums like Optional and Result, since a Some<T> or Success<T> type would have little use outside of the enum, and for enums with lots of no-payload cases, since each empty case is likewise of little use as a type independent of the collection of cases.