I'm a big proponent of this (clarity at the point of use, even over brevity), but I think people have made really good points about it flipping from helpful to noise for functions with unlabeled arguments, like operators or max or even converting initializers. The danger in those cases is around overloading based on type, and that's always going to be a concern for Swift.
I'm against the "disambiguate as needed" approach because it makes it harder for library authors to change their code. If a method has a sensible base name, and you want to add functionality that would share the same base name but uses different argument labels, you shouldn't have to worry about whether someone might be referring to the method with just the base name. I think a lot of the reason this feels weird is because argument labels aren't considered part of a method's name in many other languages, but we do think they are in Swift and have been moving the compiler in that direction for a long time.
(I'm also against the "methods and properties should not have overlapping names" suggestion, but I think that's only one of the motivations here.)
EDIT: I forgot to post my conclusion: "so I support the middle ground where foo can refer to foo(), foo(_:), foo(_:_:), etc., but not to foo(bar:) or foo(_:baz:)".
DOUBLE EDIT: …even though, ugh, this is going to be annoying to implement.