The cases where I personally wanted Pin were cases that I think will be solved in the future as async improves, but there are probably other more fringe cases which wont.

Otherwise it is impossible to become productive with that part of the language.

If they use async code as just a more office synchronous/threaded code, with purely linear control flow, then no knowledge of Pin is required. The users just sprinkle awaits and are good with it.

If users also explore the areas of which are more unique to async code (e.g. real concurrency, select!, custom combinators, cancellation mechanisms, etc) than they will indeed run fairly early into Pin.

I guess the majority of users who anticipated async/await fall into the first category. Most projects and requests around async code seem to be "just" webservers which handle some APIs. That will likely be the domain where one can live fairly well without Pin - at least if you do not implement the underlying webserver.

If the goal was for users to just use high-level web frameworks, and when there is something that the framework cannot do (which is currently a lot), the expectation is that users should just shrug their shoulders and tell their bosses "Sorry boss, Rust can't do that", then sure, there is no need to understand pinning. But such users do not need to use Rust either, an pretty much any other programming language like Go or Python would have been a much better fit for them.

I don't see any use case in which understanding pinning is not necessary.