I tend to agree with you about tools. I have yet to meet a language feature that's more important than library availability, profiling, autocompletion, documentation, debugging, etc. Then again, I don't face the script/C/CUDA choice everyday (most of his detractors on this thread don't either, I'd be willing to bet) so his circumstances are probably different enough to justify a different priority list. His argument might be perfectly valid for the HPC community which is a powerful constituency among academic programmers.
However, he did address library availability, and that argument resonates with me. I've never met a FFI I didn't come to loathe. I've had java, ruby, and python FFI libraries fail to satisfy my needs despite half a dozen bugfixes between them. What this man says about having to write wrappers, despite abundant and loud promises to the contrary, is completely true. You don't have to wander far off the beaten path before a typical FFI goes belly-up. POD structs usually suffice (Sure, we support POD structs! Oh, you want to nest them / align them / make arrays of them / have them hold pointers / ...? We don't support that "yet". Worse: they support it but it's buggy.). Heavens help you if your argument has (gasp) an initializer or one of the arguments is a reference. Maybe things have changed in the last ~5 years, but I doubt it.
If Julia's intimate connection with LLVM makes it practical to implement a better FFI or hybridize FFI + wrapper code when necessary, it will have a very valuable advantage over python for purposes of scientific computing. Maybe even enough to displace it in the long run.
EDIT: By "hybridize" I mean that the ability to embed asm,C,C++ in Julia with the same ease that you can embed asm in C/C++ would be a KILLER feature.
