By making keywords all caps, (and presumably no other user defined names are all caps...I'm not sure if this is enforced by the language or not, but it's a simple enough convention that there is a very low likelihood of it being broken) you ensure that you have the entire namespace of words available to you as keywords for future enhancements to the language.
------------
5. The next compiler version will add a new feature
Once a compiler version is released programs will be written and distributed. The next version must not break the existing programs. Thus it must be possible to add keywords, types, modules, etc. without worrying that this might break someone's carefully crafted code.
Keywords are all-caps. No user symbol may be all-caps
Builtin type names are all lowercase. User types must start with an uppercase letter.
Builtin module names are all-caps. User modules must contain a lowercase letter.
Predefined methods start with an uppercase letter. User methods must start with a lowercase letter.
This may seem a bit strange at first, but one gets used to it very quickly. And the compiler gives a clear error message when making a mistake.Because SQL has so many opinionated style guides rather than the One True Way I really enjoy spending time, if I have it, on making my SQL as Uniform and legible as I can. Sadly this is all closed source code nowadays. But my SQL files look almost like a table with clear 'rivers' along keywords. It makes my OCD brain go a little fuzzy inside when I finish :) Also having worked on a MONSTER of a financial system powered by stored procs and autogenerated SQL, I'm talking million line SQL files you can't load in a GUI, I am very fond of legible small SQL scripts nowadays.
[0] https://gist.github.com/mattmc3/38a85e6a4ca1093816c08d4815fb...
In Go fields are made public by starting their name with an upper case.