Which in some ways makes a lot of sense, in particular if you want to avoid "undefined behaviour" or just behaviour which is subtle.
For example: If I add a uint32 and a uint64, what is the format of the result? What about uint64 and int32? Which of those is "larger?"
And that's just the least bad example, with two float-formats you can lose precision is strange ways.
So I think go forcing the programmer to be specific is painful in the short term but helpful in the medium to long term. Bugs should go down and maintainability up.
In the first example, it's trivial to add uint32 and uint64, and store the result as a uint64. No information is lost at all in that operation. This generalizes to any combination of integral types, where [u]int{x} + [u]int{y} = [u]int{max(x, y)}. It's inexplicable to me why a language wouldn't allow these loss-less operations to be implicit.
The other two operations don't have a clear answer, so it makes perfect sense to require an explicit cast in those cases.
Because in some sense implicit behaviour is bad behaviour. It makes it unclear what the code does.
A 128-bit integer (if you are adding a 32-bit integer and a 64-bit integer, the smallest power-of-2-bits representation guaranteed not to have an overflow is 128-bits, so its the safest result. Though, I'd agree, not the most likely thing most programmers would intend.)