For code like
A = A + B, that can compile down to one or two machine instructions, each taking a certain number of cycles.
No interpreter can do the same thing in that number of cycles for a simple reason.
The interpreter also executes an instruction set of its own (call them byte-codes, p-codes, intermediate language, whatever).
Each time it sees a byte-code like ADD, it has to look it up somehow and branch to the code that does the addition.
The next time it sees it, it has to repeat that lookup, unless it has a way to remember the prior lookup.
If it does have a way to remember the prior lookup, it is no longer what we call an "interpreter", but rather a just-in-time compiler, or JITter.
On The Other Hand...
For code like
callSomeFunction( ... some args ...), how many cycles are spent between entering that code and leaving it?
It all depends on what happens inside
It could be a few, and it could be trillions, even if
callSomeFunction is itself compiled.
If it's a lot, there is no point in debating the interpretation cost of that line of code - the money is elsewhere.
Remember interpreted languages have a value of their own, such as, no need to compile them. (The "compilation" of surface syntax to byte codes takes trivial time. Take R or MATLAB, for example.)
Also, there is flexibility needed for intelligent levels of programming.
In Minsky's Society of Mind, Chapter 6.4 B-Brains, there are A programs that deal with the world, and there are B programs that deal with A programs, and there can be further levels.
Programs that write and manage other programs can be more easily done in interpretive systems.
In Lisp, you can write
(+ A B) to add A and B, but once it is written you only have the choice to run it or not.
You can also write
(eval (list '+ 'A 'B)) which constructs the program and then executes it.
It could construct something different.
The program's subject is another program.
This is easier to write in an interpreted language (though, as Jörg points out, newer versions of Lisp, while they have
eval, compile-on-the-fly, so they do not have the speed penalty of interpreting).