Ah, I did not 
I was too captured by the benefits.
But then, mixing control flow syntax with expression logic might actually not make Swift simpler but rather foster the confusion that I just had.
There are countless ways to syntactically marry the two concepts but they would necessarily feel forced, contrived, inconsistent, compromised, arbitrary ...
This reminds me of the discussion around result builders, which also involve familiar looking scopes that don't allow much familiar code. Only this pitch here repurposes syntax whose look, meaning and behaviour are already established. I'm not saying repurposing is bad per se, I'm just seeing all these little (or not so little) evolution steps that gradually make the language more complex, and I'm wary of that.
Entertain this possibility for a moment: Five years from now, new hip languages will pop up to replace the old generation, and their value proposition will be: It's simple, consistent and quickly learned but just as powerful. Swift got too complex and inconsistent because its open-source evolution process lacked the strategic oversight and wisdom to see the language as a whole and the direction it went.
This argument is not at all countered by the intent to disclose complexity on demand and make new features optional and non-breaking. People will use all those features combined to write code. And then other people (whom I pity dearly) will have to read it.
We tend to underestimate how making a system a little more complex increases the cognitive load in understanding and using that system: The user would sometimes see a switch block that really isn't one and would see an if-else block that really isn't one. And then, whenever she does see a real switch- or if-else block, she would have to look twice. And even though that would just take moments, it would gobble up brain power overall and feel yet another bit more draining.