Fetch -- like a lot of this promise crap -- seems too complex for its own good whilst simultaneously crippling the most important parts of request handling. It does a great job of LOOKING easier, but once you try to do anything real with it everything goes bits-up face-down. The end result actually being harder despite the initial appearance of “ease”.

The same thing that makes frameworks like jQuery, bootcrap, tailwind, etc incompetent halfwitted trash.

Your second "con" is one of the biggest reasons I'd never use it. Error handling is basically bupkis and I've already had clients who've been screwed by other dev's doing that. I'm an accessibility and efficiency consultant, and it's scary how many places if the request is denied, or invalid, or anything else the resultant sites just go off to never never land giving no feedback to the user, or anything to let you even try and diagnose where things went bits-up face down. That reason ALONE should be sufficient to make any sane and competent developer go running and screaming back to XMLHttpRequest.

The extra hoops for cookies, inability to cancel a request, lack of hooks for monitoring requests (see "onprogress"), the painful daisy-chaining of promises, (I hate jQuery for this derptitude, slopping it into the spec? Hell no!)

Saying "fetch" replaces XMLHttpRequestis like saying a Hummer H3 could replace a real HMMV in combat... or trying to replace a 1980’s F150 with a late 2000’s Chevy Aveo when you work construction for a living. Newer isn’t always better.

If this is the best the ECMA can come up with, I am not impressed.

But then I find most of the 'cons' you listed for XMLHttpRequestto be more myth than fact. To be fair though, I monitor status codes and even leverage them so I don't always have to transmit data in my returns. Something that is effectively impossible with fetch.

... and I'll shut up now before I go on a larger tirade about “frameworks”