It is the extension language for LilyPond and quite tightly interwoven with it, though both conceptual and data structure integration are an ongoing task and we have not yet managed migration to Guilev2 which would make some things easier in that regard.
In some respects, Guilev2 is a step backwards for the sake of being an extension language and a step forward for a general-purpose programming system, mainly because of its larger complexity, things like file-level byte-compilation, its more complex architecture.
Now what are comparison points with regard to Lua, possibly its largest contender?
a) Lua is minimalistic regarding its available data types and structures. It has 8 data types, one of which is opaque "user data", and one is its sole data structure, the table. There is only one numerical data type implemented as a double. This minimalism is actually an advantage for extension languages since it makes the mapping of language features to extension language features straightforward. string or symbol? Not a question: Lua interns _all_ strings at some performance impact, and so the principal feature of a symbol, constant time comparison and fixed hash code, is available with every string. Guile, in contrast, has basically a type for each purpose which makes for best utilization of machine resources regarding storage representation. It also offers more potential for performance improvement by compiling to machine code, though trace compilers (like luajit) can usually keep the code optimized for the typical use cases, recompiling when expectations are violated.
b) Lua is a procedural language, Guile is functional. This makes Lua more pleasant for imperative programming, but Guile more syntactically embeddable since there are no boundaries between "constant", "expression", "statement" and "program". If you have a mechanism for referring to a constant in the extension language, all the rest falls into place. Even the Lua command line interpreter recognizes this shortcoming and offers a shortcut "=" for evaluating and printing an expression.
c) Lua has a simple syntax for coding, Guile has no syntax for coding. Guile code is executed by reading a Scheme expression, typically a list, and evaluating it. Lists can be nested, and there is nothing like operator precedences or anything else needed for evaluating a list. That makes it less pleasant for humans to interact with Guile (like most LISP-like languages), and fabulous to have programs interact with Guile: the read syntax basically already delivers the "parse tree", while Lua can only evaluate strings. Even though its syntax is simple, you can't manipulate programs sensibly through text manipulations. Guile has a powerful macro and syntax transform system that can easily be adapted to a lot of tasks.
d) since Lua can only evaluate chunks from a string, something like evaluating user-provided material in lexical closure is not feasible (basically, you would have to splice the user-provided material into a source code string and recompile the whole function). Guile can work with lexical closure in a number of ways. Check out <URL:http://news.lilynet.net/?The-LilyPond-Report-27#a_kind_of...> for an example of tight interweaving of user-provided material and preexisting code, crossing the border between LilyPond interpreter and Guile interpreter back-and-forth without apparent effort.
e) Lua only has doubles as numerical types, Guile has a full numeric stack with integers (arbitrary size), rationals, floats, and by now also complex numbers. If you want to do symbolic computation or other "I don't want to bother with the sideeffects from approximative results" work, that's certainly a boon.
I am a big fan of Lua's minimalism, and Guilev2 is a step backward in effortless integration due to its file-level compilation and other growing pains. And while a LilyPond based on Lua as extension language would certainly have been a quite feasible project as well, using Guile as a Scheme-based extension language for LilyPond has made a conceptual and programmatic integration possible that is not easily rearchitectable to an imperative language. There is still a lot of open potential, and the other large GNU projects showcasing Guile as an extension language (GNUcash and TeXmacs) don't have, as far as I can tell, a similarly invasive integration of code and concepts, so their language choice appears a bit more arbitrary than that of LilyPond, and there are more voices for replacing it.
Both Guile and Lua have some mechanisms to "grow with you", but Guile is quite larger at the start, and Lua more focuses on keeping good relations with your project while letting it grow alone.
Probably one of the most interesting "afterthought" extension projects using Lua is LuaTeX. Guile is harder to tack onto an existing project after the fact, you better start designing with it from the start.