The points about the JVM not being able to guarantee that your code won't block the thread apply; it's left up to you to do it. This doesn't come as any surprise to me, nor I would guess to most users of the library, so I'm not sure this is really that damning. Core.async doesn't use bytecode weaving or fork/join, so those criticisms don't specifically apply.
It's damning because, rather than outsource the issue like the library makes you think you are doing (or like anyone writing erlang code actually is doing) you still have to deal with the hassle and the risk, so you're not really buying much.
Except you're using it Clojure, which makes it easier to avoid that kind of stuff and easier to spot when you count on Java APIs directly.
I'd say that many of the issues surrounding accidentally using mutable state are fairly moot in Clojure.
Blocking still remains an issue, though there's core.async/thread for go blocks that block so that they're executed on a thread of their own.
It applies equally, core.async is a CSP implementation on the JVM, it would be interesting to know how core.async relates to this issue on the browser instead of the JVM.