EVAL Now Takes Narrower Types...
Since 2021 when the above argumentation was written, EVAL refuses to load and run TEXT!, you have to use DO.
So we could arguably comply with this theory of BRANCH/EVAL equivalence now...
...but "Same As Eval" Doesn't Hold Water...
...for several reasons.
GROUP!s are doubly evaluative in branches. They are the code that runs in order to produce the branch that runs. And I'm fairly convinced the best semantic for plain GROUP! is to not run the code unless the branch runs, consider wrapping operations that process scope for the blocks:
>> if 1 = 1 (wrap [x: 10 print [x]]) else (wrap [x: 20 print [x]])
10
>> if 1 = 2 (wrap [x: 10 print [x]]) else (wrap [x: 20 print [x]])
20
That's one rule where branches and EVAL will not line up exactly. Not to mention that branches "do heavy" voids and nulls...
And I can imagine people wanting to override EVAL in ways that give meaning to TEXT! in certain contexts, too.
It seems clear that BRANCH and EVAL are distinct operators. (or EVAL:BRANCH as a refinement? Probably EVAL-BRANCH to reduce the number of arguments to EVAL so the frames are smaller, it's a common operation...)
Given that, there's not a ton of harm in allowing TEXT! branches, but we should consider there are risks (mentioned in the original answer...)