I think his comments are correct. He state it's impossible to _reason_ about Python code. That's right. If you ever played with computer aided reasoning and software specifications, you know what he is talking about. There are actually very few languages where it's doable to reason about at least a subset of that language - most functional languages somehow are in that category. There are even fewer languages where you can reason about the full language with all constructs. I am not even sure that Haskell fully qualifies here, but that's one language where I wouldn't be too surprised if it would be possble.
But then, I think that reasoning about software is as much a dead tree as artificial intelligence - at least in the "pure" sense. There are many good ideas coming from the reasoning croud, though, so we shouldn't put them off to bad ;-)
Many new compiler optimizations actually come from reasoning about code. For example type inference is something that best works if your language is structured in a way that makes reasoning possible or at least partly possible - ML or Haskell rely heavily on it, many Lisp and Scheme compilers use it to produce much faster code by infering concrete types where possible and generating concrete code instead of generic code.
AI gave us much better search algorithms and data inference algorithms that run many optimized database engines and rule engines nowadays, btw. ;-)
So I wouldn't take his critic as too critical - it does say much more about the possibility for transparent and automatic optimizations than it says about the actual language itself. It _is_ important if you work on a Python compiler, though, as it says you a lot about the language. Efficient compilation of Python code might need a helping hand by the programmer (PyRex actually shows this quite nicely).