I'm mostly lurking here and wasn't really active in previous catch-related changes/RFCs. Truth be told I'm not really satisfied with what's currently proposed and since this will inevitably land at some point and I really like @scottmcm 's suggestion, I'd like to defend this bikeshed will all the spare bike tires I have 
First of all, I think it perfectly describes what fallible { ... } blocks are and what should do. I personally parse it as a 'fallible' expression, which naturally means 'expect a value representing a possible failure'. This aligns with the semantics, where the expression inside will always return either a Result or an Option (or other Try implementers?).
When talking about evaluating an expression returning a concrete fallible value this also somewhat naturally implies short-circuiting (how would you evaluate the expression further if you have an error early and what else would you return?), which is what it's for in the first place.
There's also another teaching/ecosystem/community benefit - people are already used to the term and despite not being as simple as try, associate it with something that returns a Result or what can fail in general. A good example might be the fallible collections RFC, fallible-iterator crate or the fallible term/Infallible used in TryFrom.
Regarding reusing the widespread exception handling syntax and:
I think exceptions are a pretty hot topic when talking about programming languages and very polarising. In this particular case I think reusing the catch syntax might do more damage than good, as I believe one could expect that the underlying code can throw exceptions and introduce non-trivial control flow where in fact we just limit the scope for short-circuiting evaluation.
However, if we were to use the exception-related syntax, I'd also lean more towards try (we 'try' to do something, rather than use it to handle errors; basically what @Ixrec said and we have a Try trait for short-circuiting).