I would love to have extensible effects and forced to choose between them would agree with you. I have always thought of them as addressing slightly different use cases though. How might a solution to this use case look with extensible effects?
That's not too bad but it seems a little on the clever side and also a little verbose for such a common use case. On the other hand, I can see the argument that general purpose sugar might be harder to understand than something more explicit like this. That makes me wonder if maybe optional does deserve the same kind of special case treatment here that it gets in many corners of the language.
If we do rely on the control-flow-as-expression approach I think that would increase the importance of coalescing optional in try? as discussed here: Make try? + optional chain flattening work together. This would improve the experience of the idiom in optional-returning functions (both non-throwing and throwing in cases where it's ok to flatten errors into nil). Without making try? coalesce optional the idiom would produce a double optional for optional-returning functions which is not what would intended or desired.