The same benefits that PHP has or strives for (for better or worse) in making many web-programming-related functions always available in the global scope (it looks like Lobster does require includes however), plus first-party support from the language itself rather than relying on multiple libraries and authors (the language author gets to deal with that), plus a consistent API for all those things shoved onto the language author instead of the program writer. More interesting things you could do would be to add special syntax to support some domain-specific task, but looking from a language with macros that sort of thing comes across as cute... For instance the gl_ functions in this language create a control flow visible at the source level:

    gl_translate(playerpos):
        gl_rotate_z(tomouse):
            gl_polygon([ [ -0.5, 0.5 ], vec_x, [ -0.5, -0.5 ] ])

> For instance the gl_ functions in this language create a control flow visible at the source level:

How is this superior to exposing control-structure like object (e.g. closures) and implementing the GL dsls as libraries? The above isn't any more readable, with an increased maintenance cost for the writers of Lobster.

I would say that available libraries is by far the most limiting factor for most languages, including (I'm assuming) Lobster.

It can be hard to say whether sugar is superior or not without having a lot of experience / pain with unsugared or partially-sugared ways of doing the same thing. In this case I'd agree with you that closures could do the job just as well with hardly any more syntactic overhead. We're also in agreement with respect to libraries. The home page for Lobster mentions C++ interop, but it's unclear without digging in how straightforward that is (e.g. if one has to rebuild the compiler).