What were you hoping for? The title is pretty clear. I mean, why on earth would "Evolution of Emacs Lisp" discuss the JVM?
> I don't have much interest in whether it implements tail call recursion or if lambdas are implemented as a macro
That's perfectly fine. Criticizing the article because it dares to discuss things you're not interested in, isn't.
The complaint is that the title is in fact unclear. If someone comes up to me saying they are going to talk about the evolution of monkeys they have two strategies:
(1) Developed protein complex A, cell mechanism B became vestigial, a sequence XYZ came from a disease which became part of the cell structure, etc.
(2) When they migrated from A to B abundant food sources meant that selective pressure caused C. Then flooding destroyed the habitat and killed off all the monkeys that weren't D and that trait can still be seen today. Etc.
(1) focuses on technical mechanisms and (2) focuses on pressures and adaptions. This article has a mix of both, but it focuses in on the mechanism and a lot less on the adaptions within Emacs. Not the interpretation of 'evolution' that I was hoping for.
Take the section on concurrency - it leaves open the interesting question of "why was there pressure to make a text editor concurrent?" and "what did they want to do with that concurrency?". The article notes that use appears to still be limited - so why did they feel pressure to implement a feature people aren't using? Are there issues with Emacs' document model that make it a royal pain to use the feature even though it is technically implemented? These are very interesting questions that fall well within the scope of the evolution of Elisp that are, sadly, not tackled by the article.
The authors haven't missed their mark, but when discussing a text editor there are more ambitious targets to aim at - like 'how does all this stuff link back to text editing?'. Few of these changes are being made because anyone sees Elisp as the future.