The rationale for the async dispose stuff in the web platform would be something like:

• This solves the confusion where you don't know whether a disposal is something you need to wait for, by sorting things into two different names which aren't conflated by default
• The AsyncDisposeStack library helps compose these, making this protocol directly useful

The abort event uses DOM event dispatch, which is asynchronous

... is it?

let controller = new AbortController();
let signal = controller.signal;

signal.addEventListener('abort', () => { console.log('aborted'); });
controller.abort();
console.log('after calling abort');

prints "aborted" before it prints "after calling abort"

on the other hand,

using controller = new AbortController();
let pages = await Promise.all(urls.map(url => fetch(url, { signal: controller.signal }));
// automatically cancels outstanding requests if any request fails

would be really nice

either way, you need to be able to model both behaviors.

// option 1: cleanup but don't abort on dispose:
using controller = new AbortController();

// this could also be: `using _ = controller.enter();` or some better name
using stack = new DisposableStack();
stack.defer(() => controller.abort());

let pages = await Promise.all(urls.map(url => fetch(url, { signal: controller.signal }));
// automatically cancels outstanding requests if any request fails

stack.move(); // empties out stack

// no longer tries to abort for any errors that follow.

// controller is disposed. since it is no longer usable, callbacks etc. can be GC'd

// option 2: abort on dispose
using stack = new DisposableStack();
const controller = stack.use(new AbortController());

let pages = await Promise.all(urls.map(url => fetch(url, { signal: controller.signal }));
// automatically cancels outstanding requests if any request fails

stack.move(); // empties out stack

// no longer tries to abort for any errors that follow.

// controller isn't disposed, any closure that captures and holds a reference to `controller` will prevent GC of `abort` callbacks

Not if you have some kind of "enter abort context" method like I mentioned above, i.e.:

using controller = new AbortController();
using ctx = controller.enterAbortOnDisposeContext(); // needs a better name.
let pages = await ...;
ctx.exit(); // exit the context without triggering dispose

I think I also disagree about which semantics are more likely to be surprising here, and how bad the surprising behavior is in each case.

the only thing AbortController right now does is cancellation, so it is natural to assume that using x = new AbortController is going to have the disposal semantics related to cancellation (i.e. abort-on-dispose). If you see that code but it doesn't do the thing it looks like (i.e. it just does GC), you're probably going to have a resource leak (e.g. requests will not be cancelled) which is very surprising to you, and you might well not even notice it (a fetch request not being cancelled is not an error you will likely notice).

Something like this is fairly easy to write in user code, or to build into the DOM API:

class AbortRegion {
  #controller;
  constructor(controller) {
    this.#controller = controller;
  }
  preventAbort() {
    this.#controller = null;
  }
  [Symbol.dispose]() {
    const controller = this.#controller;
    this.#controller = null;
    controller?.abort();
  }
}

...
const controller = new AbortController();
using region = new AbortRegion(controller);
... // abort on error
region.preventAbort();
... // no longer abort on error