A whole lot of misdesigns are only a “small amount of brain power” to use. As your language accumulates these, however, the load builds up.

This also has the extra problem that overloading in general brings with it. What is the result of 3 + "string"? What is the result of "string" + 3? You have to have rules for this. These rules have to be learned. They have to be kept in mind. There is room for error. And of course the way different languages react to them will vary strongly.

For example in Rexx, Python, and Ruby these are errors (and with the latter two the error changes depending on which order). In Awk and Perl the result is 3 in both cases.

Format strings are better than + as concatenation, to be fair, but are still not very good compared to separate concatenation operators. It’s hard to make them type-safe. They separate the value from its location in the string.

Using actual concatenation operators has the advantage of format strings, but add the possibility for type safety. For example in Ada:

...
    Put_Line("Distance: " & Distance_Value'Image & "km");
...

See here, & will only concatenate string types. If you want to print something that’s not a string, you have to convert it to a string. This means you can’t accidentally mix types. Further, it’s immediately obvious where a given value will show up in the output. Compare and contrast with the C equivalent:

...
    printf("Distance: %skm\n", distance_value);
...

Not only is location of the value obfuscated—trivial to spot here, but in a complicated string it’s very difficult to spot at times. And it’s easy, too, to have the format code not match the value. As this example illustrates. Again, easy to spot in trivial code like this, but horrifically hard in real-world code, especially if the variable type changes.