One funny thing you can do in Go is for example to create a subtype of int and change its String() method to return the hexadecimal representation of that int. Very neat.

Other type systems, like TypeScript, support string literal types, and in Typescript we generally would just define the keyword type to be a union of string literals and then use those string literals in the code.

But without string literal types, using a string constant gives the compiler more information it can use to make sure your code is correct. That's a useful thing to have.

Similar to how linters stop you from overthinking indentation in specific cases, or some naming standards, and later rename/reformat-wars.

That's what leads to dogmatic cargo-culting. Good software is written by thinking about the circumstances and doing what makes the most sense, not by mindless rule-following that don't always make sense.

I don't know why someone would be so worried about typos and introduce more verbosity and redundancy in the process; but then again, I don't use an IDE and I've never had this problem.

Good software may mean thinking about circumstances like "we're dealing with lots of text parsing and have seen bugs from typos in common keywords" and doing what makes most sense: "let's prevent those in the future, but using constants for keywords". It's only cargo culting if you don't know why you're doing something.

Setting a rule so you don't have to debate something later is a valid solution and may still offset some redundancies introduced this way.

Yep, it would be a little harder to implement all of the SQL spec in a single post. Maybe over time though.

For example when storing session state into a Dictionary<string,object> all access to the session state is through static strings, never a string literal. This makes is super easy to find everywhere that’s accessing that particular session variable.