In programming, our challenges includes some tightly coupled issues. Identifying and removing errors to large programs and keeping code complexity to a minimum. Strict typing usually eliminates a number possible errors. Unexpected autoboxing is one of them, depending on the strength of the type system. You describe adding a 0 to a string, which is how people think for a simple domain. A type is a domain. An int will (in most languages) not contain .01 nor 1i nor A. Representative values notwithstanding. So I understand your point, but I disagree that people do not think in types.
Strict typing, for the most part, increases notation complexity in naming (z = ArrayList[T,H,G] vs y=ArrayMap[L,P], ad nauseam) and an added layer of boilerplate conversion code/functions for moving between types explicitly. I'm really surprised there aren't more PHDs getting proper staticians to correlate this from the glut of Java code flying about. This is a tradeoff any time you trade compiler checking for the conversion code that had to be written to support the types being used. You have to decide if that's worth the cost of a programmer's time (let's not talk about the programmer's sanity). I think it's a great tradeoff, in many languages. Type systems aren't trivial to maintain in a language and I don't envy maintainers.
Some languages are still developed saying they don't have a strict type system. While I don't have an example for Perl, PHP definitely has a demonstrable wishy-washy type system, it's just hidden from most developers.
$z=1.5*2;
$y=array(1,2,4,5);
$t = array_key_exists($z,$y); // error! because $z is a float
Since you can't have float keys, where's the autobox there? Another function, array_slice, doesn't care and converts it to int.
At some point the compiler has to figure out if the value is representative or not. Every language has a strict type system at some level so, I have to disagree that it's brain dead to have one.
The question is, should it be a tool for the programmer to ensure code correctness or just a set of rules that usually ignore? One leads to, among other things, more robust and reliable large systems with an added benefit to prolonging the useful life of a programmer (old programmers usually end up in java because the compiler/IDE catches many problems) and the other path can lead to more rapid development, more intimate knowledge of the language to avoid behaviors like subtle bugs, and more flexibility in reusing code. Instead of a bunch of utility methods or conversion code for handling different possible types, you just use 1. I prefer languages without type systems because I primarily write and work on smaller systems, but I see the value in larger projects that use them. I'm not sure it's useful to call one side weaker than the other where there's no solid criteria for what's "best".