I didn't want to write another post about this proposal, but it looks like a discussion from the pitch is repeating, so I guess it doesn't hurt to add a short upshot.
I'm still convinced the positive aspects are not nearly as big as some people suggest, and there might still be some expectations this addition simply can't fulfill.
You loose a main feature of enums when you "hide" them behind a protocol: Depending on the exact setup, you may still be able to use switch, but the guarantees of exhaustiveness are gone.
It might be possible that those could be preserved, but I guess an idea like Enum cases as protocol witnesses - #58 by michelf might interfere with SE-0280.
Although some examples from the pitch discussion turned out to be not that persuasive, @hisekaldma finally brought up a true case where the proposal would definitely be helpful (Enum cases as protocol witnesses - #117 by hisekaldma - imho that should be included in the proposal if it is not there yet).
While there are many who welcome SE-0280 as a simplification, it is not removing exceptions from the compiler code, but rather adds some lines — but afair, the bigger part is new tests, and it's not a huge change.
However, this feature will also need proper documentation, and I don't think it will simplify the chapter about protocols...
I appreciate that this proposal has some context (Protocol Witness Matching Mini-Manifesto), and I hope this is taken into account:
The more "duck typing" is added to Swift, the more people will get used to it, so the impact of this proposal might be bigger as it seems on first sight. Coming from Objective-C, I don't fear duck-typing - but I think this is at least a slight change of Swifts character.
Overall, I don't think I would benefit from SE-0280 — but while I wish for better acceptance of critique, I don't share the strong dislike of the few opposers: Many of those who don't need the feature might never notice it.