At best, that may shave off a few seconds of the time needed to refactor.
The trade-off is code that is harder to mentally parse, because we are used to trailing commas, not leading commas.
If you spend more time reading code than writing it (which I assume applies to the majority of development), then the trailing comma is a much, much better choice of style.
I spend a lot of time writing ad hoc queries for analysis. That means I don't know what columns I want, I might be switching things up from aggregates to subsets and back. That's why you'll find things like:
WHERE 1=1
AND a.id = 12
--AND a.Col1 > 23
AND a.Col1 = 23
Similarly the leading comma makes it faster to cut out things I'm not using anymore. Now obviously for production code you could argue my reasons are no longer valid - but probably they'll leak through because that's what all my shk hotkeys generate and I'm used to writing
The time saving isn't as important as avoiding frustration in your tools. Stubbing your toe on silly problems like trailing commas breaks flow and makes exploring less fun.
In my experience, these commas don't add any real meaning to the human readers. Will it really obfuscate the code for a future reader? I can imagine it can look unfamiliar and consequentially grate someone's nerves. Reminds me of the arguments around R's "<-" vs "=".
I agree with the sentiment for most code, but I doubt I spend as much time reading my SQL queries as I spend writing and refactoring.
The trade-off is code that is harder to mentally parse, because we are used to trailing commas, not leading commas.
If you spend more time reading code than writing it (which I assume applies to the majority of development), then the trailing comma is a much, much better choice of style.