We can go back to the reason that Pin even exists in the first place. With Rust, you create a computation, and it implements the Future trait. When you want it to execute, you give it to an executor. This often moves the data structure that represents the computation to the heap, so that it has a stable address, and can continue running after the current stack frame is over. So, before the future starts executing, it can be moved around in memory (and probably will at least one time), but after it starts executing, it must never move again.

Does that make sense?

So the main use is convenience to seamlessly make stack variables permanent? Intuitively that doesn't sound worth the language design troubles compared to making the programmer declare these things on the heap manually. I'm not that familiar with Rust though.

That’s one use case, it’s not the only one. And it’s not always “put it on the heap”, so you can’t solve the issue that way.

Ideally it should be possible to avoid the heap entirely; futures in Rust should be capable of operating even in contexts that don't come with a memory allocator, such as memory-constrained embedded devices.

Rust’s ownership model is used to provide memory safety. Entities have only one owner so that the compiler can reason about when they go out of scope and can be safely dropped. If x didn’t get invalidated by the move then both x and y would own the entity. You could then do something like pass y into a function that would drop y at the end of the function scope, and then cause a use-after-free by using x. With the ownership model the compiler can guarantee that use-after-free is always a syntax error. The ownership model is a fair bit more complicated than this, but move semantics are at the core of it.