For me all of them have a different purpose. By default, if you want sequential code: Async/Await. More readable.
If you are in an event driven code (with a trigger that can be called several time), you have to use callbacks.
In some very specific cases, I use promises, for instance to have a queue of operation

I use promised more out of not being fully comfortable with async/await yet, even though async/await seems like the better tool for the job in a lot of cases. But I always hated callbacks, so anything else is better. 😄

async-await - but sometimes it just makes sense to use a then with a traditional Promise.
We should remember that async is nothing but a 'wrapper' or syntacic sugar for a Promise - it's not wholly different thing.
async just makes our code a bit easier to read as it 'looks' 👀 synchronous. And, no callback is needed, mostly. 👍🏾
Callbacks are generally just for 'event based' UI stuff, such as addEventListener.

Async/await is actually implemented based on Promise so the differences are mostly in how you code.

Promise

Promise sucks when we need variables across multiple then, yet this can be solved by an additional local variable:

var local = {};
getPayload().then(function(payload) {
    local.payload = payload;
}).then(function() {
    doSomething(local.payload);
});

This local variable in Promise case serves like the local scope of the async case.

Async/await

On the other hand, In async/await you need try/catch to handle exception, which induces possibly nested code segment if you have complicated logic to handle:

try {
    await payload = getPayload();
    doSomething(payload);
} catch(e) { .... }

The counterpart of try/catch in Promise is the catch function.

which one?

I tend to still use Promise than async/await because:

about exception handling

While Promise still nests regarding complicated error-handling, it's also more "functional".

about local scope

While we need an extra local variable in Promise, codes and variables are segregated in their own scope inside then function call.

This may be opinion-based but I think it's less error-prone since only variables with local prefix are accessible across all functions.

And callback function?

Since Promise.then(function() { }) is actually a callback pattern, we are using it all along. But will choose Promise if possible. :)

I actually jumped from callbacks to async/await. Promises for some unknown reason just didnt capture the "full fix" to the problem for me. I had battled callbacks for a long time and I think smaller, cleaner functions ended up reducing the amount of callback hell I hit in a single implementation. I started to notice posts on various blogs discussing the endless .then world too.

In the end when async/await came along it felt like the most natural method to writing code, without the nesting and ultimately more readable.

Callbacks always leads to callback hell. If I start something and end up needing more than 3-4 asynchronous calls, I will always refactor to async/await if for some reason I start up with callbacks (it happens, particularly if I start from an example).

+1 — The code is cleaner and I won’t end in callback hell. Or have strangely nested Promises because I need values from various responses.

Async await when there are multiple async actions, but I don't mind using callbacks for simple stuff like running a function after 2 seconds seconds using useTimeout.

Well, Promises and Async/Await are basically the same, so I use both of them but I don't use callbacks because I don't like them.

RxJS, Async/Await, Promises, callback functions. This is my list of tools composed by preference priority.