(posting in personal capacity, not as review manager)
I think this is a mischaracterization. The proposal itself does not make this its primary argument, instead opening with the case that return takes up disproportionate space in simple function declarations. And the strongest support on this review thread and elsewhere seems to come from the improvement it brings to both reading and writing computed properties.
Consistency is certainly a secondary argument though. The proposal suggests eliding the return on functions will "help prepare new Swift users to understand" closures, which I think is a reasonable point. Elsewhere I've suggested that the consistency with closures makes this proposal an easier bit of sugar to accept, because that consistency means the sugar arguably lowers the complexity of the language, unlike other sugar that relies on adding new features to the language.
There's some pushback here to applying this change to functions even if we accept it for getters and subscripts. My personal opinion is it would be OK to not do it for functions, but the consistency of applying the same rule across the board means its worth doing and outweighs the reasons to not.
I find the choice between closures and functions to be a lot blurrier than others seem to. For example, suppose you find yourself writing
numbers.map { $0*2 }
Maybe for readability or because you are using this closure in a couple of different places, so you give it a name:
let double = { $0*2 }
numbers.map(double)
But then it turns out you're using it on not-integers, so you have to give it some type context:
let double = { i -> Double in i*2 }
At this point you're getting close to "may as well make it a function" territory:
func double(_ i: Double) -> Double { return i*2 }
To push it over the edge, you might want to make it generic, which would have to be a function:
func double<T: Numeric>(_ i: T) -> T { return i*2 }
At what seems like an arbitrary point in this otherwise smooth transition up the ladder of expressivity, you are forced to introduce a return. Why? Seems arbitrary to me. Not a big deal, maybe, but this is somewhere the consistency would make the language better IMO, by smoothing transition between these two forms. So while I'm strongly in favor of this proposal for the purpose of getters, I'm also in favor of it applying across the board.