CPS is one approach to asynchrony, since you can interleave continuations when scheduling them in the event loop. And that's exactly what this thing does.
As to why it's better as part of the core library - I'd say the biggest benefit is that there's a standard API for a future/task abstraction. This way, any async library is composable with any other library (in theory; there are still some warts that make it harder than it should be, some of which are described in this article).
Interleaving continuations is cooperative multitasking; Async is about non-determinacy: you have more than one process/job/thread/core/socket/&c. and you don't know when they will run or need servicing. (I.e. select().)
Broadly speaking async processes are not composable. We have "theories" like Communicating Sequential Processes, and things like the SPIN model checker, but a bunch of plug-and-play libraries that just work is a pipe dream, I'm afraid.
I think it's a terminological ambiguity. Most times, when I hear people speak about "async" today (or speak about it myself) what they really mean is "non-blocking". And such use has been common for a very long time now - for example, in .NET 1.0 (2001), the standard pattern for non-blocking operations has been to for the function return an object implementing IAsyncResult.
As to why it's better as part of the core library - I'd say the biggest benefit is that there's a standard API for a future/task abstraction. This way, any async library is composable with any other library (in theory; there are still some warts that make it harder than it should be, some of which are described in this article).