The difference, though, is that the sweet.js example of classes aims to implement something that is traditionally a language feature. APIs tend not to do this.

You might argue that the distinction between APIs and language features is arbitrary. But I'd say there is a meaningful difference. An API helps you tackle a particular problem domain, such as making an HTTP request, communicating over a USB port, or writing an image. Whereas a language feature is much more generic. It's not limited to any particular problem domain. Rather, it cuts to core of how we express problems in general.

If we're all ostensibly writing JavaScript, I don't think we should be using multiple, incompatible variants of the same language features.

As Dave Thomas (of OTI not pragprog) said once. "Its important to be able to debug at the level of the abstraction". So in theory making up a language is the same as writing an API. In practice when you are in a hurry trying to fix something and your livelihood depends on it you may end up cursing the macro writer. I do think they can work when there's only one person on the team, which sometimes happens, or if the team are mature and disciplined, which rarely happens. They can also work in any team for trivial stuff like logging etc.