> If you need to do that you now have to think about it and explicitly convert a number into a string.

You have to think about it either way, the feature precludes forgetting about it.

> you can make mistake of concatenating a number with a wrong string or make some other screw up

Which you can make in both cases.

> because your thinking power is now reduced.

Your thinking power is not reduced, it's increased: you don't have to wonder whether you should convert something to a string or it already is one, the compiler will tell you, so you can focus better on the actual work at hand.

No, if conversion is implicit you don't have to think which function to call, where to find it and which library to include. Quite significant cognitive overhead I'd say.

Having separate concatenation operator with implicit conversion could reduce that overhead:

  a := "foo" ~ "bar" ~ 123

Instead of:

  import "strconv"
  
  a := "foo" + "bar" + strconv.Itoa(123)

But this is not how Golang guys make decisions. And I'm fine with that nowadays as long as they don't claim to be right in that regard.

The interesting code for this example is:

  c := a + b

There's no indication from that line of code what a and b are, a type system that doesn't do implicit conversions will tell you "error: adding string and int" and so the programmer can address the problem (e.g. maybe they meant to parse an integer from the string `a`, maybe they meant to format the integer `b` into a string).

Using literals is not a useful comparison because there is no confusion about types in that case.

My bad, I thought it was obvious from having separate operator for concatenation that '+' operator also has only one intent. So in your case it will parse an integer from a string if operand is a string.