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..
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.