I saw that talk and I can tell you that he looked very confused. He was just in the need for an excuse to develop just another scripting language. You could see that he had not much experience with Lisp and that Lisp was not something that he actually needed. I think he knew Lisp mostly 'in theory'.
If you think that he is a pretty smart guy, then I would say that there are many Lisp implementations that are way ahead in terms of implementation technology - Matz's Ruby implementation is in the Lisp world several decades behind the state of the art. Ruby is one of the slowest scripting languages and has a very much ad-hoc design. It does useful things for many people, and that counts. But from the technology it is Ruby that is a huge pain in the ass. Just see how people struggle to write a decent compiler for it. Instead it is just another simple interpreter with a C core for the interpreter implementation and parts of the library. Ruby is fast where you stay in with the library functions that are implemented in C - otherwise it is a pain.
The better Lisp systems are also written in Lisp and their performance is sometimes 10 to 100 times of what Ruby offers - while Lisp offers also lots of dynamic features and the code as data paradigm.
Started with BASIC: 'I could Make Intelligence'. ???
Then he found Lisp in a magazine article and 'fell in love with it'. 'BASIC aristocracy' vs. 'Lisp democracy'???
He liked Lisp from a book, but 'unfortunately he did not have a computer that could run it'. In University he used Emacs Lisp and it did not make him 'happy'. Parentheses? No? He had no problems with it. Macros? Partially. 'Smart people just underestimate oridinarity (sic) to use Lisp'. 'We are too ordinary to use Lisp'. Aristocracy. He is happy with aristocracy, as long as he has power.
The whole point is that there's more to languages than just "technical correctness". Lisp is great technically and theoretically, but in other respects it is quite a ways behind (for instance) Ruby. So Ruby has some big problems (speed, to use everyone's favorite example) but just saying "Ruby is slower so we should all use Lisp" is a bit ridiculous. That's what he was trying to say.
(He's also not a native English speaker, so i cut him some slack on that front.)
I was not talking about 'technical correctness' (though the literature how to implement languages does exist - just start with Steele's papers - Steele describes efficient compilation some thirty years ago), but about 'technical capabilities' - and it that area Ruby is lightyears behind Lisp implementations. I'm also not saying 'Ruby is slower so we should all use Lisp', I'm saying: Ruby is much less capable than Lisp, so it neither is a Lisp nor is it able to replace Lisp for the tasks where people use Lisp. For an expert Lisp programmer there is little reason to use Ruby anyway. Ruby has a larger user community, but that does not help me when Ruby simply does not provide the capabilities I need - the user community could be ten times larger and the number of libraries could be also even larger. It does not help if the libraries that I'm interested in are not available and probably never will.
Matz designed Ruby for so-called 'ordinary' people with him to do the language design. I can tell you for sure that I neither like his design nor do I want him as the language designer. In the Lisp world the implementors role is to empower the user, not make them dependent. I need a new control structure? I write one myself. I don't have to wait for some benevolent dictator, who probably does not get basic designs right - just look at the confusion of blocks, lambdas, etc. in Ruby.
(also there is no excuse for putting confused stuff on slides, even when he is not a native speaker - lots of people (including me) are no native English speakers and I haven't sensed this amount of confusion Matz shows)
That Lisp is too complicated for some people is not news, still Emacs (which he tried) now comes with a standard library of a million lines of Emacs Lisp code for all kinds of editor extensions. Emacs Lisp code that has been written by very different people and obviously a lot of them learned enough Lisp to write sophisticated applications based on Emacs (like GNUS, calc, the various mail modes, org mode, ...).
Lisp is also not only great technically and theoretically, but some people found it practically. There weren't ten maintained Common Lisp implementations if there were no users for it. For example the talks at the Lisp Meeting last sunday here in Hamburg described several applications in Lisp: an airline reservation system (developed by a team of hundred people, fifty of them Lisp programmers), a visual reactive programming system, an aircraft analysis tool, a reasoner for the semantic web, a visual simulation system, machine learning applications and some more.
If you think that he is a pretty smart guy, then I would say that there are many Lisp implementations that are way ahead in terms of implementation technology - Matz's Ruby implementation is in the Lisp world several decades behind the state of the art. Ruby is one of the slowest scripting languages and has a very much ad-hoc design. It does useful things for many people, and that counts. But from the technology it is Ruby that is a huge pain in the ass. Just see how people struggle to write a decent compiler for it. Instead it is just another simple interpreter with a C core for the interpreter implementation and parts of the library. Ruby is fast where you stay in with the library functions that are implemented in C - otherwise it is a pain.
The better Lisp systems are also written in Lisp and their performance is sometimes 10 to 100 times of what Ruby offers - while Lisp offers also lots of dynamic features and the code as data paradigm.