In Herb Sutter's words, avoiding auto since it makes the code "unreadable":
...reflects a bias to code against implementations, not interfaces. Overcommitting to explicit types makes code less generic and more interdependent, and therefore more brittle and limited. It runs counter to the excellent reasons to “write code against interfaces, not implementations”
See http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...
I believe Stroustrup is correct that we're all beginners at some point, but we quickly move up. It makes more sense to optimize for "proficient, but not expert" than to optimize for "beginner," because more people are at the proficient level, and they stay there longer.
I agree that code shouldn't be unnecessarily complex. But I would quit any project that constantly brought up "but what if a programmer were brand new when they looked at this code?" in reviews. Then again, if other programmers have the same reaction, perhaps the project really would be full of nothing but beginners.
The second issue (async) is quite similar in my opinion, and in practice your async handler will be explicitly decoupled and strongly typed at some point for reasons of testability so the example is describing also an OO design issue and not an issue with auto.
There may be real problems with auto but this article did not provide any compelling evidence of them.