It is worth considering (I mention this, because it has been brought up in a previous comment) that no, Ruby, does not have comma-less parameter lists or array / hash literals. It does however have syntax shortcuts like the following:
%w(first second third) == ["first", "second", "third"]
%i(first second third) == [:first, :second, :third] # list of symbols
and a couple of similar shortcuts.
However, these are of a very different nature. Regardless of whether one believes that the complexity added is worth the benefit, at least one can argue that allowing people to omit commas and quotes (for strings) or colons (for symbols) has tangible benefits especially for people using Ruby for e.g. scripting; it just saves a lot of keystrokes. Furthermore, the scope of these declarations are very limited: it's immediately obvious that this special syntax will only apply within the scope of the
%i() construction, so there should be no ambiguities.
By contrast, I simply do not see how a single comma between arguments / array elements makes a huge difference in terms of readability and I've certainly never considered it to be a "pain" in any way, no matter how DSL-y my code looks like. If anything, I would support special sugar for more specialised cases as in Ruby where the benefit is more striking and the context of this sugar is limited in scope.
Even if it didn't have any obvious downsides, I fail to see how this proposal is in any way addressing an actual problem within the Swift language (as opposed to some extremely subjective ideal about "code beauty"). The only argument I can see that I would personally attach any value to is the "minimizing diffs" one, but a) this could also be mitigated by allowing trailing commas (as mentioned several times) and b) let's be honest, git is a great tool and probably the best we have, but it kind of sucks at diffs anyway, because it has zero semantic information about the programming language, and there are 200 other things I wish git could indicate to me in a better way (e.g. when a method has been extracted) that routinely cause confusion in code reviews, that this minor nuisance is just really not that bad.
This coupled with the fact that it can cause real problems in some cases e.g. involving operators on the next line etc.—which might not be a "problem" for the compiler but certainly can be one for developers who might fail to understand the error messages—leads me to think that this feature does not fit in with the direction of Swift and would be a bad addition.