That is not the problem here. The problem is that this might by the code piece "x + y" where x and y is in your scope and happens to be [] and {}. The resulting value is then highly confusing to a programmer. A language that enforces explicit type conversion (some call these strongly typed languages) would not allow this, but require you to write something like "string(x) + string(y)" if you really wanted such behaviour.
"I can't imagine a single situation where you expect variables used in a sum operation to be arrays/objects."
That's precisely the problem. You don't expect them, but there's nothing to prevent it from happening, so it does.
Your proposed solutions don't solve the problem, they occur too late. By the time you're adding together two non-numbers (and non-strings) you've already lost, trying desperately to cast them to numbers first is also wrong, along with so verbose that nobody will ever do it.
I think it is rather bad semantics actually.