The actual reason why let ... in syntax tends to not use C-style "var type" like syntax is because it's derived from the syntax type theory uses, and type theorists know about parameterised types. Generics, in C++ parlance, excuse my Haskell:

let foo :: Map Int String = mempty

We have an empty map, and it maps integers to Strings. We call it foo. Compare:

Map Int String foo = mempty

If nothing else, that's just awkward to read and while it may be grammatically unambiguous (a token is a name if it sits directly in front of =) parser error messages are going to suck. Map<Int,String> is also awkward but alas that's what we're stuck with in Rust because they reasoned that it would be cruel to put folks coming from C++ on angle bracket withdrawal. Also Rust has ML ancestry don't get me started on their type syntax.

let a: &'static str

String a: new String()

Good, now invent a keyword for variables you don't want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.

Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.

python:

a: str = 1

Because sometimes that let can be replaced by other things like const. Which can be managed statically by the machine and not by my (imperfect) ability to know if it's mutated or not

You're encoding more information in the typescript one. You're saying it's a string that will get updated.

Not to short-circuit the joke, but in this case, it's because the valid JavaScript version is...

let a

...and one of TypeScript's main design goals is to be a superset of JavaScript, that only adds syntax, and doesn't re-write it.

Beyond that, it's probably a case of some new language just using what the designer is familiar with.

I've always wondered where all this 'let' business started