There are very useful things which you can easily do with async/await which are essentially infeasible with callbacks. Also the logic is a lot more succinct and descriptive.

Imagine that you invoke multiple functions which take some time to complete and you want to execute some logic when they're ALL done. It's a real mess with callbacks, how would you do this? You could have a separate variable or property for each callback which records which callback completed and then you keep checking it until they're all done... Such code looks very messy. People who use callbacks tend to avoid even thinking of problems in those terms because they're afraid of having to write such code. But in reality, it's a very common problem; especially when you're processing data; some processes take longer to complete than others and you need to aggregate multiple streams together before passing the processed results to the next stage.

Also, how do you handle errors? A problem which requires only 20 lines of async/await code that flows neatly from top to bottom will require you to write at least 200 lines of code with callbacks and you'll end up building callback pyramids where the logic will jump all over the place and variables scattered everywhere. Much more error-prone.

If you can write the same logic using much fewer lines of code, why would you not? It really comes down to that.