If the syntaxic sugar is just a different way to express the same thing without adding any facility, it offers no interest at all. It gets interest only if if adds some behavior (e.g. avoiding repeating a subexpression, without having to declare a temporary variable, or create a separate block of statement to isolate that temporary variable (this is the case for example with the for statement) and programmatically have to handle the scope (so that the abbreviated form also gives hint to the compiler or optimizer about which temporary variable is no longer in use or must no longer be used, and so that common subexpressions can be evaluated only once and their result kept in an implicit variable/register); the same is true for the colon-syntax for functions to pass an implicit "self" argument: the code is clearer in that case, and less errorprone, so the syntaxic sugar has demonstrated benefits.
However a basic "sugar" changing the syntax of a simple function declaration offers no benefit, except possibly to provide additional hints or restrictions on the outer variables in scope that are explicitly allowed to be used in the closure, and make these variables being explicitly named (yes in that case, it provides a clear code, and allows better isolation so that additional vairables which may be present in the closure would be implicitly hidden/inaccessible: the compiler can then use it to optimize these hidden variables to not pass them inside the closure, and the compiler can then reorganize the storage order and allocate the hidden variables only inside the parent function/block, possibly only on the stack and not adding any key in the table of variables for the parent scope, and closures can then be optimized and reduced in size, while enforcing a good programming style where dependencies are explicited; another interesting extension would be for these closures to have local name bindings: local names used inside the function would no longer have to be changed inside the function even if the outer scope has changed the name or its own binding; allowing as well easier refactoring of the code, including for testing local changes to an implementation). Note that function declarations already embed some existing syntaxic sugars (including for the declared name, which in facts hides a declaration of a local variable initialized with an anonymous function, and hides the hidden parameter pointing to the closure structure built with upvalues.
So a syntaxic sugar must just be made to add other missing facilities (that are otherwise too complex to write without being errorprone): it should be used because it allows clear code and easier detection of programming errors (notably an accidental use of an outer variable in scope of the enclosing closure, whereas the function code should have declared its own local variable: in Lua there's no protection and it's easy for a programmer to corrupt unexpected variables in the enclosing scope, just because of a simple typo in a variable name and even linters won't help until there's a manual human scrutiny of the function's code: here a syntaxic sugar would help by offering a stringer isolation of the valid scopes, enforced by the scanner or the compiler). Other sugars could provide additional facilities for debugging or introspection/reflection and could also offer additional features like declaration attributes.
