Many expressions have to produce an independent value that the evaluating context will has independent ownership of: functions have to return independent values, getters have to return independent values, and so on. Other expressions don’t: most importantly, references to stored variables or properties. (This is all getting more complicated as we introduce more support for lifetime-dependent values, but for now, this is the big picture.)
The big concern about implicitly forwarding values is that forwarding necessarily means the caller loses access to the value. If the caller actually needs the value to stay alive, either because it’s going to use it again or because the program as a whole has an implicit dependency on its lifetime (e.g. because of a weak reference somewhere else), the forward can break behavior.
But that’s really only a problem with expressions that don’t naturally produce an independent value. If you use a call expression directly as an argument for a consuming parameter, the current context doesn’t have any other way of referring to that result, so it obviously can’t directly use it again later. Along similar lines, forwarding it could end up shortening its lifetime and invalidating weak references earlier, but it doesn’t really seem reasonable that someone would expect the the current context to keep this temporary value alive arbitrarily. So there’s no good reason not to implicitly forward into the parameter.
Yes. The callee simply receives a value that it has ownership of, with no idea how that was produced.