On the other hand, function parameter lists are (usually) short, and a trailing comma *might* indicate that something was deleted that shouldn't have been
That's an illusion ! In reality, code could have been deleted anywhere else in the middle of the list, and the syntax does not offer any protection, unless the code is made to ensure that items are counted, or the list contains a way to verify its content.
But real code editing requires a policy and many tables are generated, with data uitems added and removed constantly in random position, that does not need to take into account if these items need a trailing comma or not.
If you don't fix it, it breaks; code is safer and simpler to manage by allowing commas (in fact that trailing commas should have even been mandatory, the syntax with commas only allowed as separator should be deprecated as being potentially dangerous. Most projects have code generators and editors that expect to use fixed formats on data rows, the concept of having a separator that MAY be present before but not always, and MAY be present after the row but not always, causes more problems. It breaks common operations anc complexifies the use of data parsers, regexp searches.
So I have the complete opposite position to everything that you argued. Allowing commas EVERYWHERE is the best option (and the even better position would be to enforce their presence, not just allowing them).
