I use it as my day to day scripting language, and also for parsing (with LPEG, which is awesome), general prototyping, etc. I tend to use Lua as a standalone language and as a nicer interface to C and its libraries, rather than embedded in mainly-C projects.
A couple personal projects I have going in Lua at the moment are 1) a language-independent tool for locating copy-and-pasted code that has been modified in place, and thus is hard to locate via simpler tools such as grep (which I hope to release this summer); this has involved research and a lot of dead ends trying various parsing-based techniques. It's a surprisingly tricky thing to do well. 2) a randomized testing framework (think QuickCheck) for Lua, which is usable, but needs more polish and documenting before I release it, 3) a profiler with different analysis than LuaProfiler, 4) an RSS library, and 5) a bunch of other wrapper libraries in various stages of polish. I have a wrapper for Redis (more idiomatic of Lua and a bit faster than the official one), a library for mpd, a wrapper for xosd, and other such odds and ends. There's probably stuff I'm forgetting. I start too many projects... All of the above will be released under one of the BSD/MIT-ish licenses, when/if I feel they're polished enough.
Overall, Lua has taken over the niches for which I used to use Python or Chicken Scheme. It's a really nice language, especially if you're comfortable with a bit of C now and then. It's not good for everything, but its design is refreshingly modest about just ducking out of the way and letting you use other tools when they're a better fit. (Its minimalism and prototype-based object system also appeal to me.)
There are a bunch of other little tools in my bin directory that I should clean up and share, but that's probably true for everyone here.
I always thought that Python lacks marketing (f.e. comparing to Ruby), but now I understand real meaning of the words "lacks marketing". Lua should be spread wider.
Also, Lua is in a bit of a unique situation, because probably half the people using it (give or take) are using it inside of an existing project, which would provide most of the libraries they need. Also, the Lua team has intentionally made it easy to fork local dialects of the language, which in many cases are probably too nuanced to be of general use. (It's MIT licensed, so there's no requirement to contribute back.)
http://lua-users.org/wiki/LuaUses
http://en.wikipedia.org/wiki/Lua_(programming_language)#Appl...
I use it for general scripting purposes, but it's you run into many more roadblocks than with Python or Ruby due to the lack of libraries. However, there are a range of decent libraries available and packaged using Luarocks. The Kepler Project (http://keplerproject.org) might interest you.
By the way, it's Lua rather than LUA.
* I decided it would be better wait and post once LuaJIT 2 is actually released, so we can test it ourselves.
* The fact that he's comparing it against C's performance is because it's more useful to say, e.g. "75% as fast as C for benchmark X" rather than "47x faster than Ruby", since the speed of obsessively optimized C is usually the de facto target for such benchmarks. It isn't necessarily because it's beating C yet, just drawing closer. (Considering how dynamic a language Lua is, that's remarkable.)
FWIW: In my typical day to day use (as opposed to narrow benchmarks), swapping Lua for LuaJIT 1.1.5 leads to a 2-4x speedup, with no other changes to my code.
I'm really looking forward to LuaJIT 2, in part because it is expected to be more easily ported off i386. (I often work on amd64.) I use non-JIT'd Lua a great deal, and it's already quite fast. I care less about raw speed than expressiveness and portability, though -- I really like how expressive Lua is, while keeping its semantics simple enough that it's still easy to reason about. (That its simplicity makes it possible to write a top notch JIT-ing compiler for it is just icing on the cake.)
Here's a roadmap for LuaJIT 1.1.4 and 2, from last February (http://lua-users.org/lists/lua-l/2008-02/msg00051.html). It also has a bit of info about how JIT/traceing compilers work, and suggestions for further research.