I would welcome this change if only because using single statement returns is already very practical in contexts of properties and using a switch or chain of if statements to determine a value instead of using an inline closure, and breaking down complex lines to achieve this would be a good thing. Most importantly though, as the pitch outlines, adding any single line to these constructions after the fact is tremendously disruptive, and holds the potential to introduce bugs in the re-write rather than augment or fix an issue. I'd imagine those that are against this style could use a linter to avoid it (and the existing instances of it) in their own code bases, as I don't see how lacking a return at the end of such statements could cause actual problems.
The only argument against that I could think of is forgetting to mark the return type of a function, and not getting the diagnostic that the return statement disagrees with the value actually being returned, but since Swift enforces the return type, and would warn if you tried to use a function and assign it to something, I can see disaster being avoided (well, at least in most situations… async let returnValue = functionMissingReturnValueButMeantToReturnSomething() may lead to a few surprises, at least until await returnValue is used?)
To those arguing that this will end up just like goto fail, do note that there are different ways of solving that problem as well, than just saying {} braces are always needed. Consider a same-line requirement, for instance:
if (someCondition) return; // Would succeed
if (someCondition)
return; // Would fail to compile
I've similarly argued simplifying the language not for if statements, but for guard else statements, that are almost always two word return statements that read better without the {} getting in the way. I similarly don't think leaving the return statements out gets in the way of reading familiar, or even unfamiliar code — we are poor readers of code to begin with, and removing extra keywords will likely help parse code more quickly as our brains were skipping the ceremony already without most of us realizing it.
It's been almost a decade and a half since I learned of this, so forgive me for being unable to quote the study, but from a human language point of view, redundancy in speech is a good thing because it helps us catch phonemes that are dropped or hard to hear — this is why we conjugate verbs despite other words surrounding them giving us the same information. In written language though, redundancy tends to complicate things quite a bit — via eye tracking, it is largely skipped over (though different groups from different languages focus on the different redundant part), and many learners of a language, typically children, second language learners, and people with reading difficulties like dyslexia often misapply the redundant rules. The argument that written language should have settled by now to be most optimal falls through when we look at the largest literate group we have ever seen: people on the internet — I'm sure everyone here knows someone who speaks properly, but leaves almost everything out when texting, no matter their age 
Point being, I see dropping the return statement when it can be safely inferred to be more welcoming to all involved that will be coming to Swift. Those that wish to include redundancy when writing the code still can, and will get the additional benefits of the compiler checking their work, but when the redundancy isn't necessary, I will surely welcome the lowered mental overhead.