This remains a very irritating thorn.
But I am 100% convinced that branches need to take GROUP!s literally (and not run the branch generation code unless the branch is taken.)
So we have to now ask how convinced I am that you need to be able to write:
except e -> [...]
...instead of being forced to write:
except (e -> [...])
Kill Your Darlings (?) 
Historically I've been proud of how the avoidance of the GROUP! is accomplished, as it was technically quite tricky...
...but this "cleverness" has costs. (Not the least of which is explaining that the feature exists at all, and how it works!)
Plus I've mentioned that if you don't have the GROUP! there, the arrow has to run unconditionally...AND it has to produce some kind of ACTION! regardless of if it's going to be used or not.
I'll mention the need for literalism has pushed groups into more places. e.g. things like FUNC have to take their body literally now, or else it can't inspect a FENCE!'s top-level set-words to fold them into the frame.
Hence we can't write:
foo: func [...] compose [...]
But have to say:
foo: func [...] (compose [...])
(Although there's a backdoor with foo: func block! [[...] [...]] if you need it, in code composition scenarios where you don't want groups.)
So if you find you have to write:
except (e -> [
...
...
...
])
Instead of:
except e -> [
...
...
...
]
How bad is it the group really? It's more cognitively honest. It's better for performance.
This Is A Tough Call
I will definitely say that accepting the GROUP! for generative code in function bodies has reset my thinking.
And when I think about the scenarios of some of the most "showcase" code (like UPARSE) I would have to use a GROUP! anyway, because of the performance impact from not using one.
If I can't use my "clever" feature in showcase code, where should I use it?
Not to mention the fact that TRAP has gotten rid of the pattern (e -> [return fail e]) which was the most common place where this mattered.
Future Versions Could Override My Call
Let's say I'm wrong. You would have always been able to use a group.
Maybe this is the best argument of all. Take it out, stop worrying about it, let the future worry about this one. ![]()