It is normally only on minimalisting target platforms, where it is a important advantage to remove the build step. That was why all our early microcomputer platforms had to settle for interpreted languges. They had a very simple and small "text-to-token" filter. And then they walked through these tokens, running a minimalisting virtual machine.

Today, compiler technology have reached a level where there exists a number of incrementative compilers. They can process a source file, pick up the single changed function, generate new virtual or native machine code for that function and then perform an incrementative linking with the rest of the program in almost zero time.

A number of compilers/linkers can even do that in the middle of a debugging session, and patch the running program on-the-fly and then let the developer continue single-stepping after having fixed the error. After the debugging has ended, the patched binary can be thrown away and the linker can create a fresh binary that does not contain the buggy code blocks that was patched around.

In the end, there are only really four situations (that I can see) where interpreted are good:
1) When the interpreter must run on the same hardware, and that hardware is tiny.
2) When target transfer times are very slow, so we don't want external builds and then wait for uploads but instead want to be able to make patch the application directly inside the target.
3) When there is a big advantage to be able to run self-modifying code - like having an end user supply a complex formula to a graphing web service.
4) When the language itself is extremely suitable for a specific problem, and there are no suitable alternative of a compiled language (too high price, not possible to run on target, licensing restrictions, ...)

I was pretty sure I had a fifth reason for interpreted solutions too, but sems to have dropped out of my mind while I was writing the first four. ;)