Q:

Why not auto move if object is destroyed in next step?

If a function return a value like this:
std::string foo() {
  std::string ret {"Test"};
  return ret;
}

The compiler is allowed to move ret, since it is not used anymore. This doesn't hold for cases like this:
void foo (std::string str) {
  // do sth. with str
}

int main() {
  std::string a {"Test"};
  foo(a);
}

Although a is obviously not needed anymore since it is destroyed in the next step you have to do:
int main() {
  std::string a {"Test"};
  foo(std::move(a));
}

Why? In my opinion, this is unnecessarily complicated, since rvalues and move semantic are hard to understand especially for beginners. So it would be great if you wouldn't have to care in standard cases but benefit from move semantic anyway (like with return values and temporaries). It is also    annoying to have to look at the class definition to discover if a class is  move-enabled and benefits from std::move at all (or use std::move anyway in the hope that it will sometimes be helpfull. It is also error-prone if you work on existing code:
int main() {
  std::string a {"Test"};
  foo(std::move(a));

  // [...] 100 lines of code
  // new line:
  foo(a); // Ups!
}

The compiler knows better if an object is no longer used used. std::move everywhere is also verbose and reduces readability.

A:

It is not obvious that an object is not going to be used after a given point.
For instance, have a look at the following variant of your code:
struct Bar {
  ~Bar() { std::cout << str.size() << std::endl; }
  std::string& str;
}

Bar make_bar(std::string& str) {
  return Bar{ str };
}

void foo (std::string str) {
  // do sth. with str
}

int main() {
  std::string a {"Test"};
  Bar b = make_bar(a);
  foo(std::move(a));
}

This code would break, because the string a is put in an invalid state by the move operation, but Bar is holding a reference to it, and will try to use it when it's destroyed, which happens after the foo call.
If make_bar is defined in an external assembly (e.g. a DLL/so), the compiler has no way, when compiling Bar b = make_bar(a);, of telling if b is holding a reference to a or not. So, even if foo(a) is the last usage of a, that doesn't mean it's safe to use move semantics, because some other object might be holding a reference to a as a consequence of previous instructions.
Only you can know if you can use move semantics or not, by looking at the specifications of the functions you call.
On the other side, you can always use move semantics in the return case, because that object will go out of scope anyway, which means any object holding a reference to it will result in undefined behaviour regardless of the move semantics.
By the way, you don't even need move semantics there, because of copy elision.

