Just append a random constant at the end of every SELECT column list instead, 42 to the rescue! (I kid, I kid.)
I can't tell yet whether my experiment starting an all-OR WHERE clause with 0=1 so each OR could start the next line would go over like a lead balloon here too or not.
One thing I've actually found useful especially in SQL is always including a single-line comment in front of the closing of every multi-line comment, so that using a single-line comment to toggle off the opening of the multi-line comment toggles the entire block back into action and the end is already set (the closing comment is itself already commented out). This obviously doesn't work if multi-line comments start nesting, but that can confuse parsers enough already.
Trying to get an entire team on the same page with SQL formatting is one of the mothers of all bikesheds. In any case it's useful to be aware of the idioms whether or not they are personally palatable.
SQL has so little room for expression or opinionated formatting, so it's funny to people bikeshed over comma placement. I'm kind of jealous that they have time to think about whether left comma or right comma offends them greatly.
To be fair, BigQuery SQL is improving at quite a pace. If you follow their RSS, they are often announcing small but solid affordances like trailing commas, the new RANGE datatype, BigLake, some limited grouping and equality for arrays and structs, etc.
It is also probable that they expose Google's new query pipe syntax. Currently there are some hints from the error messages in the console that it's behind a feature flag or something.
Which ones?
Postgres, Oracle, SQL Server, MySQL, MariaDB and SQLite do not allow that.