You can also just include all of Lua's (or LuaJIT's) code directly into your game if you don't want a separate DLL.
Binding libraries are designed to make it easier to glue your C/C++ and Lua code together -- e.g. 1 line of code per function, instead of a dozen.
They also make everything act the same way -- e.g. With manual binding code, you could accidentally pop the wrong argument, or forget to push your return value, or forget some type-safety checks; a binding library ensures every bound function does all these actions in the exact same way.
Also, Lua is *not* an object oriented language (it does not have classes as a built in feature), but it is so flexible that it's very simple to implement OO features like classes and class-inheritance yourself, in Lua code.
Often a binding system will do this for you (implement classes) so that your C++ OO code can be sensibly translated into Lua.
The guys behind the
BitSquid engine do actually recommend *not* using a binding library, and instead doing all your binding work manually using the Lua C API. Their reaoning is that these binding systems are often very inefficient, and that they hide a lot of important details, such as big differences between C/C++ and Lua. They say that by doing the binding work yourself, your Engine's Lua API will be much more Lua-oriented, rather than a C++-oriented API that's been shoehorned into Lua.
Personally, I found the existing binding libraries that I surveyed to be way too bloated and inefficient for my tastes, so I wrote an extremely simple one for use in my engine, where most of the time I can bind things to Lua with one line of code, but sometimes need a few more in complex cases - a kind of middle ground between the raw Lua API, and something like luabind..
