I have been trying to add a Forth-like scripting language and REPL in my C# development environment (for a LOT of reasons), and I've been wrestling a lot with the difference between interpretation and execution. Even after being in the industry for many years, I did not expect to be able to switch back and forth between compilation and interpretation so quickly and so effortlessly. Anyway... I have realized that compilation is really translation from one form of code to another, usually textual code I've written, into MSIL, a bytcode for the .NET framework virtual machine. But if I do some Windows Forms development, and use the screen editor, I've created code using a GUI editor, and under the covers, it generates C#, or I might be remembering my FoxPro from long ago. It doesn't matter -- the point is that there are multiple representations of source code and multiple representations for the destination code -- and that's the compiling part.
But the compiled part is usually the "frozen" part, and can not change, can not be sculpted to fit the problem at hand. Especially not the way interpreted code can. So that's the first reason for interpretation -- to achieve flexibility at the point of use.
For the interpretation, anything that runs code is interpreting. So, clicking a button is interpreting your action of a mouse click, and running code off of that. So, every application is an interpreter, or more accurately, a whole suite of them. So, your question becomes, "Why do they embed an additional interpreter?" Changes the perspective quite a bit, doesn't it? And then if we start thinking about the XML files and YAML files being used as configuration files for an application, well that's yet another set of interpreters. Even when you compile down to machine instructions, those raw bytes are interpreted by the microcode inside of the chip.
Interpreters are everywhere.
The bible of software development that I found, Code Complete (second edition), states that we developers tend to write the same number of lines of code per day, so instead of writing assembly language, we should be writing in a DSL, a domain-specific language, created and targeted to be most effective at the job that needs to be done. For configuration, that's YAML, or a database table, or an *.ini file. For a game, that might be a LUA, embedded to script it. And we work hard to create a DSL to have the most expressiveness, to deal with just the abstractions at hand and focus on only those, and to be able to ignore everything else, to be able to try to limit complexity, and yet express my solutions to my problems as simply and as powerfully as I can. So that's another part of your answer. To enable and empower the user.
We embed an interpreter in order provide a vocabulary and a set of tools so that we can express the solution to the problem at hand in that dimension (or domain), with maximum ease, simplicity, and power. An embedded interpreter is a Domain-Specific Language, a set of tools, along with the words to use them. Why embed a DSL? To get it done faster, simpler, or to give us a NEW ability to solve problems that we could never solve before, and hopefully solve them correctly. And hopefully more succinctly than I have expressed this answer ;-)