Due to my code being used across a few different projects, I ended up rewriting a lot of it. I eventually insulated the stable code and ended up with some quite extensive scripting (due to historical reasons, the script is proprietary).

For a lot of games, you could get away scripting nothing. Yes, I wrote script nothing. Fact is you should first go through data-oriented design first and then add scripting to manage all those cases where data alone does not cut it. To do this effectively, keep in mind what you want to accomplish.

Say for example we want to make a breakout clone. Do we want to use scripting? For first iteration sure not. We build levels using pure data.

Do we need scripting in a breakout clone? Maybe to design a new powerup? Or for a new enemy?

New enemies from breakout does not seem to be so complex to require scripting to me. For powerups, it might be useful to script them since they're often very varied in effects but due to their limited number maybe we might still want to make them code.

The very important thing is to not think in a vacuum. Always think in your context first and in the near-to-mid term future then.

In my case I usually only add in scripting support once it reaches a certain level of complexity. For tool programs, rarely do they get any scripting unless I need customized options to be stored and reloaded (I can use the registry for that until it hits a certain level), For games, definitely since I prefer to have the game logic and data separate, this makes adding a new planet, asteroid field, starship, system, GUI window, trader and etc. trivial with no recompile required. Change the script and relaunch the program. I don't use Lua, I use my own custom parser but the functionality is nearly the same. It really depends on the size of the project though....