The commit wars will be long and bloody.

Partially, yes. I personally use an IDE with excellent syntax highlighting and those have been around for at least two decades. You are, however, often transplanting your SQL between a variety of environments and in some of those syntax highlighting is unavailable (for me at least) - the all caps does help in those rare situations.

More importantly though it helps clearly differentiate between those control keywords (which are universal) and data labels (which are specific to your business domain). If I'm consulting on a complex system that I only partially understand it's extremely helpful to be able to quickly identify data labels that I'm unfamiliar with to research.

it's 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times

You say that as if AS400 systems with only console access don't exist anymore.

Please tell me what IDE you're using that's capable of highlighting SQL syntax that's embedded inside another language source file

Also please fucking stop with the "it's current year stop x." The year is not an argument.

Also some people are color blind.

Also you might need to ssh in somewhere and vi some code or tail a log file where you don’t have color support.

Yea - you want the structure in a recognizable form so that you can quickly confirm code patterns for comprehension.

I've seen both approaches and I think they're both quite reasonable. An indented join is my preference since it makes sub queries more logically indented... but our coding standards allow either approach. We've even got a few people that like

FROM foo
JOIN bar ON foo.id = bar.fooid
JOIN baz ON bar.id = baz.barid

Actually not. It's part of the FROM

I'm quite aware... basically it means that novice devs can create a table in camelCase and query in camelCase... but you can clean it all up as long as they didn't realize you needed double quotes.

I tend to use underscores on join tables so table foo_bar would have a fooid and a barid. I have somewhat soured on this approach though since there are a lot of situations where you'll have two m-m relationships between the same two tables with a different meaning... and having a fixed formula for m-m tables can make things ugly.

If I get to design another greenfield database I'll probably prefer using underscores for word boundaries in long table names.

That too, singular table names just makes a lot of stuff more automatic.