Enums are really powerful, you can do a lot with them (albeit with a lot of boilerplate). With private cases, they'd get even more powerful. Still, that doesn't mean they're always the best solution for everything.
Protocols provide an abstract interface over a set of types. That is certainly one of the things that enums can do, but protocols are designed for that kind of work and are generally more expressive. For example, you can't mimic associated types with an enum, because you'd need functions to have different return values based on the dynamic case. Your only option would be to return another enum.
It also does require less code. With both enum-dispatch and protocols, there will be a declaration, and every type needs to implement that requirement. For enums, if you have M types and N requirements, your declarations need an additional M lines to account for the switch statement which is done for you dynamically by fetching a protocol witness table (or statically, by the optimiser). So that's another MN lines.
Another really important point is that sealed protocols don't need to stay sealed forever. As the open/public class proposal explains, designing a base class which appropriate for subclassing is not trivial. In early development, you might make superficially non-breaking changes like rearranging the order in which certain open methods are called, and accidentally break somebody's subclass. The same is true of protocols - designing a truly abstract interface like
Numeric requires a lot of thinking and careful documentation. We made lots of changes to
Collection over the years (the new index model, removing
Numeric gained inheritance from
Addable a few weeks ago, which is technically ABI-breaking. A protocol which is sealed while you work out the requirements can be opened to external conformances at any time.
Sealed or not, protocols are the best thing for type erasure, not enums.