// using Promise.race so whoever finishes first wins
    var fetchingWithTimeout = Promise.race([
      
      // first promise: actually try to perform the computation
      fetching,
      
      // second promise: wait x seconds, then reject
      Promise.delay(x*1000).then(Promise.reject('Timed out')),
      
    ]);

In cases like a node.js server, Promises allow a single node instance to handle thousands of concurrent requests because the event loop isn't blocking waiting for a single IO request to complete, the process can happily do lots of other things while Promises are pending.

I agree that if you have some pure linear steps (do A, then do B, then do C, and probably use the result from the last step for the next), then the synchronous abstractions work fine. But as soon as you add various timeouts, different error handling strategies, multicast communication, cancellation and other stuff to your async IO procesing then it isn't purely linear anyway. I often end up implementing quite complex state machines for heavy IO related code, and for this I am more happy with working in an asynchronous single-threaded environment.