It seems unlikely to me that we would want to generalize ErrorProtocol; my expectation is that all errors need to be able to get caught by and propagated through existing code that isn't aware of noncopyable types. (Boxing them could get us there, though, I suppose.)
If noncopyable errors ever become a thing, I see no reason we couldn't generalize Result in a separate followup proposal, if and when it's time to do so. (For existing projects that use Result, these generalizations aren't disruptive changes -- no existing API gets deprecated, and (hopefully) there will be no need to migrate anything or to rewrite any existing code. Unless of course someone wants to adopt the new features.)
However, I think it's important to highlight that this is definitely not going to be the final proposal that messes with these types. I don't expect Optional & Result would cease evolving after the changes in this pitch ship.
In fact, we already know for sure that this is not their final form!
While this proposal is targeting Swift 6, over on Swift's main development branch non-escaping types are starting to take shape, too. Once they become a thing, we'll eventually need to have a second round of (smaller-scale) generalizations to allow Optional and Result to hold those, too. Ultimately, these types will need to become not just conditionally copyable, but also conditionally escaping.
Jumping from where we are in Swift 5.10 directly to that target would be way too large a leap: it makes more sense to go step by step. This pitch is opening new frontiers that are worthwhile on their own right. I think it's good to allow some time to explore this new space and get comfortable with its properties, if only to better understand why we need to take the next steps.