1) No, it isn't. Despite the terse code, execution is slower. Think 1MHZ CISC vs 50MHZ RISC, RISC requires more instructions to get the same thing done but it executes them much faster, making up for the program length difference and finishing the task way ahead of the CISC.
2) Then it wasn't a "pure" interpreter. Much better but still much slower than compiled. The border is blurred, take the tokenized output from such interpreter, add the language library and you got "compiled" program. Even C in many aspects works like that (requiring LIBC or such).

3) These aren't micro related problems. The mentioned overhead of an interpreter makes interpreters an interesting but hardly usable branch of programming for micros.

I wonder how the "ladder languages" for PLC work though. These may be similar to interpreters, where the gfx gets replaced to sequence of simple calls and conditionals to specific highly optimized routines. So, even though "compiled", they still retain a lot of interpreter characteristics - very small chunks of user-created code drive bulky system pre-compiled routines.

BTW, I've met eeprom software for a '52 clone that allows tracing/debugging "step by step" of the user program using serial line. How do you think? Did it work with some hardware or was it kind of "asm interpreter" or "'51 simulator in a '51"? I think such a simulator (a designated Xram piece to simulate the scratchpad, SFRs and such) would be possible and interesting (though I can't think of many uses for it...)