It's handy for creating DSLs. For example, I'll point to SpringRTS, an open-source RTS gaming engine.
There are three concerns that make an embedded language good:
1) Lockstep multiplayer. Each player has a full copy of the gamestate on their client. Every action performed against the gamestate is done in sync on every machine in a deterministic fashion and order. This means that any custom code must be written with preserving sync in mind - something as simple as rand call on the clients would break sync. So Lua allows the engine developers to properly restrict the users to only use libraries and language constructs that will respect the sync (it fails at this, but it's a goal and Lua helps with that).
2) Code from peers. Users develop code for other users - widgets that help on the user-interface and games for each other to play. A sandboxed environment is a must.
3) Graceful failure. If a widget fails it doesn't bring down the whole engine with a segfault.
There are three concerns that make an embedded language good:
1) Lockstep multiplayer. Each player has a full copy of the gamestate on their client. Every action performed against the gamestate is done in sync on every machine in a deterministic fashion and order. This means that any custom code must be written with preserving sync in mind - something as simple as rand call on the clients would break sync. So Lua allows the engine developers to properly restrict the users to only use libraries and language constructs that will respect the sync (it fails at this, but it's a goal and Lua helps with that).
2) Code from peers. Users develop code for other users - widgets that help on the user-interface and games for each other to play. A sandboxed environment is a must.
3) Graceful failure. If a widget fails it doesn't bring down the whole engine with a segfault.