Both are legitimate styles, for some situations, and none is universally better than the other.

If you are dealing with event sequences that are predicated in some way (only go in one direction, delay until another event has finishes, HTTP, etc.) then synchronous code is a superior choice for clarity. It expresses the core idea of the algorithm very cleanly.

If you are dealing with receiving many events at the same time (like keyboard/mouse input etc.) and the events are not predicated (or not much) callback styles are often a better choice.

Which style you use should not be dictated by your language/runtime environment and technical issues, but by your usecase.

An issue with imperative/synchronous semantics arises if the only way to service this semantic is blocking system calls (like recv). You can use threads to migitate this problem, but in its stead just introduces locks, raise conditions and blocking semaphores.

A better way to provide the ability to handle events in an imperative/synchronous fashion is to use non-blocking system calls (connect ex, set blocking to false etc.) and use co-routines to schedule micro-threads depending on event state. There have been a variety of blog posts and papers about this, which consistently show that for I/O bound tasks, this is a far superior model because it offers cleaner code than both callback/asynchronous events and threaded programming, while also enjoying speed benefits forgone by threads (due to locking).

There are three primary ways that co-routines can be implemented:
1) As an native code level instruction pointer switch, an example of this would be pythons greenlet implementation.
2) As a property of the virtual machine running the interpreted language, an example of which would be rubys early thread model (didn’t use actual threads).
3) As a preprocessor to the virtual machine input that translated synchronous marked up codelines to asynchronous code.

These options are not entirely equivalent and some have advantages over others.
1) Implementing micro-threads/greenlets/co-routines on a native code level is quite fast. It also automatically solves the case that a virtual machine level callback is performed in a native-code part which was not designed to support micro threads. However there might be messups of the VM state.

2) Implementing them as a property of the VM is a very safe and relatively easy thing to do, however inbetween native-code parts and callbacks to virtual machine code, the micro-threads could get broken by inconsiderate native code.

3) Implementing them as a preprocessor is a very inferior choice, because it requires code path inference. In other words, if A calls B and B calls C and C is defined as a co-routine, then B must know that C is a co-routine, which means that A must know that B is a co-routine. Since this is not possible in JS, every call would have to be a potential co-routine, which would be extremely slow and would produce extremely convoluted code (compared to relatively straightforward code as produced by Coffeescript).

However the problem is solved in the end, sticking your head in the sand is not the solution.

With a true asycnrhonous event model you can imagine a more pure PaaS solution where your stateless application can really be running anywhere. I think then economics will drive to PaaS over IaaS.

As far as I understand it, the need for callbacks arises from the wish to better use computing resources: The code is divided into small blocks of non-blocking code, that optionally end with a call to a function that is blocking.

When structuring the code like this, the runtime will only need to create a thread or two for each core the computer has, and these will get these small chunks of code from a queue, process them, and give the blocking pieces back to the queue manager, which will add the callback to the queue when the blocking call ends.

When you tell the language which functions are blocking, you can write your code in a synchronous/sequential style, while the compiler does the work of making it work efficiently.

[...]  

if (some contidion) {
    x.result = await someAsyncOperation();
  }

  await x.save()
[...]

If what happens here obviously is synchronous (as, using “await”, things don’t seem to move any further until x.save() or someAsyncOperation() has finished), why would I want to make it asynchronous, after all?