[jan_Inkepa]

Large areas of ridiculous behaviour are, if easily characterised, maybe easier to avoid than more finely-graned edge-case zones that you'd get in more elegantly top-down designed languages, and result in less mental overhead. "just stay clear of doing anything remotely weird with arrays" might result in better, more readable code than a langauge with more easily-understandable array behaviour, and have lower mental overhead than what you might get in a better designed language where it might feel more feasible to keep in mind the edge-cases.

I've made a scripting language for videos games that some people use, and kept the semantics super informal, growing it quite organically, and it's worked out pretty well. Every time I try to nail down the edge cases I think "ah no, I'd prefer to have this all be undefined/erratic that to have people rule-lawyering their way into technically-correct but inelegant code". The main loss I've had from this is the inability to write a fuzzer, and in annoying some people (who use it or, for instance, wanted to write compatible compilers/interpreting). I do rely a lot on test suites for it (which also helps other when they want to do reimplementations), which provides a good amount of stability in spite of the fact that I never tell anyone what exactly counts as a valid variable name and amn't exactly sure what that is off the top of my head.

That said, nicely-specified programming languages that one can accurately comprehend + model with a human brain are super nice, allow for great tooling + better portability, and eliminate a large class of bugs that can be very troublesome. I'm a big fan of Go/C#, but they're not everything, and not from my point of view at all categorically better than other options.