Well, there's a whole bunch of magic, from virtual memory, to linking, to branch predictions, all the way to microcode, that's not clear, so there's that.
(In computing there's not magic. There are abstractions, and it's not that always less is better).
To validly complain about an abstraction the abstraction should make reading the code (or other aspects, e.g. performance) worse.
Merely complaining that "it hides things" and that you "have to learn it to know what it does" is not a valid complaint.
That's literally what abstractions are supposed to do: hide things and introduce new things to learn (the abstraction.
So you can't use the fact than an abstraction like async/await hides things ("magic"), or introduces something new to learn, as an argument against it (unless you're against all abstractions, but this train has long sailed, and the question whether abstractions can be good is settled: yes, they can).
So, the whole point to judge an abstraction is whether the new thing it introduces makes things easier _after_ having learn it or not.
So far your arguments were just that it hides things (magic) and that callbacks made what happened clear (so, again, the hiding aspect).
(In computing there's not magic. There are abstractions, and it's not that always less is better).