It's fairly common to cancel an HTTP request. The new fetch API doesn't let you cancel a request as a consequence of this shortcoming of promises, while XMLHttpRequest does.
Not sure, but does this mean that I can't cancel a heavy file upload if a user changes his mind?
So I cancel my GET request, all is fine with the world. I cancel my POST, and now I have no idea at which layer it was cancelled, if at all. Certainly the cancel doesn't propagate to the server.
I've used cancellation in C# and agree that it's super useful, but it's not a panacea and has to be handled thoughtfully. JS can manage without it IMHO
Canceling them is now a big deal if it's needed.
Personally, I think they could be handled by the WebStreams API, so when you want to "cancel" a download or upload, you just throw in the function which is consuming or creating the actual data which will reject the promise entirely.
However only ReadableStreams are available in some browsers right now, and WritableStreams are still a bit away AFAIK, so it's not possible to do that right now with promises, but i don't think that warrants adding even more features to a language which will most likely never be removed.
Those applications that already aren't robust to this (I sadly assume that is most) aren't going to be helped by cancellation
Due to the very nature of asynchronous operations, it is, in general, impossible to even determine which layer will ultimately handle that request (e.g. in your example, whether the POST won't happen, or it'll be aborted, or it's already completed), much less how it'll be handled.
The assumption is that all layers will do their best effort (defined vaguely in a "common sense" way) to service that request.
That is a very useful abstraction to have, and I don't see why JS is special in that regard.