Its poor design to compile data into your game. It's good design to interpret as much logic (game rules*) as possible. The main purpose of scripting is to pull as much data and logic out of your compiled binary.
* Game Rules include algorithms that govern how combat is handled, how AI select behaviors, what items do- etc. They do not include actual number-crunching algorithms (like searching the state tree).
Why? Easier to patch, update, localize, maintain, modify, balance, edit, serialize, network, implement visuals and create supplemental design tools for. Your game is no longer just the executable, but all of the assets, scripts, and data that surround it.
Why not? Fair amount of overhead. Complicates your program's architecture. Slower loading times and run-times.
How? For good experience, make your own parser! You don't need a formal scripting language. Just read lines from a text file and use that information in factory methods to set flags and and initialize a library of items, monsters, potions or spells. Then, you can have another text file provide parameters for level generation-- test it out. Create an interactive console that lets you add something to the library or choose the parameters for the next level to be generated. Scripting is just being able to pass information to a parser that modifies the application state accordingly.
After you're done reinventing the wheel, incorporate Lua into your program. You can shove SQL in there too for no-brainer serialization (though technically you can just store all of your data as Lua tables).
Why Lua? Because writing a parser is hard! Writing a parser with support for flow control is super hard! Lua is fast and easy... and very portable.
Oh, PS: Sandboxing in Lua is the equivalent of setting a flag.
