In 1991, when this was written, C was dominant and yes, Lisp was comparatively slow. Today Lisp is generally faster than Java, PHP, Python, Ruby and other popular languages.
I expect they have, and that modern JVMs would win, it being a fair and balanced contest. In the unfair and unbalanced real world, however, a Java application is likely to spend a lot of time processing XML while its equivalent Lisp application gets to enjoy the efficiency of an s-expression world.
XML processing in a typical Java application tends to take place up front, being used to build runtime representations of the same information. XML exposure over the longer term will tend to be in the context of communications with other applications where Lisp has no particular advantage. So the XML impact will mostly be present in startup costs only.
If the Lisp apps are conversing only with other Lisp applications then to compare like with like you need to look at Java Serialization not XML.
I was going to write a nuanced reply dissecting the parts of what you posted I agree with from the parts I disagree with. But I decided that would be too much minutia. The important thing is that Java and most Lisps are in the same general performance class. People have found success with the slower performance class represented by php, python and ruby, so today it makes no sense to describe Lisp as slow. I think we're in agreement on this.
We're still waiting for a useful programming language or environment that has something significant that wasn't done first (and usually better) on Lisp machines.
