The only benefit I can currently think of is that you can make some coding updates, via Lua, without having to recompile.
Do not discount the utility of this so easily. You will never understand how productive you will be until you take away the recompilation step.
The "flow" is a fairly well-understood psychological concept when it comes to work. The flow is that feeling you get when you're focused on an activity, when you're analyzing and solving problems almost without thinking, etc. You are at your most productive when you are "flowing".
Compile times screw all of that up. It's hard to stay in the flow if you have even a 10-second compile between testing something.
When you are developing gameplay, what you usually have is a "tight loop". You have an idea, you code up a test to see if it works, and then you try it out. If it doesn't work, you modify it and try again. The "code-to-test" time is very important for maintaining flow. Getting it as small as possible is crucial.
What Lua (or any embedded scripting language) allows you to do is to test changes, not just without "compiling", but live in the game. Depending on how you build your game, you can run a command that will restart the game with new scripts without having to stop and reload data and so forth. Not only do you not have to recompile, you don't have to re-run.
The ability to do this, given the proper engine support, can dramatically increase productivity.
Another major benefit to scripting is the ability to just not care. If you've spent a long time writing C++, you would be amazed at how much time you spend over minutae. Where memory is deleted. Where this gets freed. Even if you're using
shared_ptr everywhere, just the act of typing in all of those variable type names slows you down.
In a dynamically-typed scripting language, you don't have to care. Scoping is simple. Functions are first-class objects; you don't have to manually build functors. It is just so easy to do some things.
Now that does have negatives, if you're not a disciplined programmer. It's very easy to use globals in Lua (though there are ways to prevent that). Not caring means that you can be very sloppy when you code.
But then again, being very sloppy can have advantages.
This is useful for configuration files; Lua's table format is a lot better than .ini formats. The format is still rather clean, compact, and extensible.
Oh, and it's still a Lua script, so it can perform actual logic. The downside of that is... well, it's a Lua script, so it can perform actual logic. That could be disastrous in game, since the user could potentially start screwing things up.
But actually, this is easily dealt with. Lua is designed for embedding, which means that isolation is actually quite easy. Indeed, a fresh Lua state provides nothing by default; you have to actually do something to expose even the most basic of the standard Lua libraries. File access, game-state access, etc, is all opt-in, not opt-out. And each Lua state is separate from each other one. The Lua state you use for AI scripts does not have to be the Lua state you use for config files.
I actually have some code that allows you to register many Lua standard libraries, but goes through and removes all file IO. Ultimately, the worst that a Lua script-based configuration file could do is cause your game to crash immediately upon running it, by running it out of memory. And since you're not sharing these config files manually, that wouldn't be much fun for a hacker.
I would say that the biggest downside of any scripting language is debugging. Most scripting languages do not have debuggers, and Lua is no different. Lua does have all of the tools one would need to build debugging tools. But it does not actually have a debugger built-in. You have to put one together. And that's going to require a reasonable degree of work.
Or you can make due with "printf debugging". It really depends on how much Lua code you write.