Only when you have an object that implements [Symbol.dispose]. If you don't, then you need to create one (like the wrapper in the example from the article) or bang out some boilerplate to explicitly make and use a DisposableStack().
So with using there's a little collection of language features to learn and use, and (probably more importantly), either app devs and library devs have to get on the same page with this at the same time, or app devs have to add a handful of boilerplate at each call site for wrappers or DisposableStacks.
Fwiw, most backend frameworks and libraries where this sort of functionality makes sense are already using a polyfilled Symbol.dispose that will transparently work with the real thing if you start using it in an environment that supports it. I've been using this feature for a while via transpiled syntax, and it works pretty well.
On the frontend I suspect it'll take a bit longer to become ubiquitous, but I'm sure it'll happen soon enough.
`using` is mostly more convenient, because it registers cleanup without needing extra calls, unlike `defer`.
And of course you can trivially bridge callbacks, either by wrapping a function in a disposeable literal or by using the DisposableStack/AsyncDisposableStack utility types which the proposal also adds.
