This allows you to write fast code in julia, which is impossible in python (you can call into very fast C/Fortran libraries with nice bindings, though).
On the other hand, I really hate the syntax. One-based array indexing (ok, minor), blocks ending with "end", and most importantly unicode support.
Really, who thought that it was a good idea to allow symbol names that are unreachable on a standard US keyboard? WTF? This makes it supremely inconvenient to use libraries that happen to export symbols with crazy names. If you must, specify a name mangling scheme and let people who want to see crazy symbols use an IDE. Seriously, am I supposed to use a hex-editor when auditing julia code?
I totally agree with the author that package discovery and uniformity are a big problem. Indeed, this is even moving in the wrong direction: More and more functionality is removed from Base and put into external packages. I would prefer a more "batteries included" style, with uniform quality and documentation for standard functionality (splitting into different namespaces is good, though), python-style.
Second non-cosmetic problem is that the language documentation is atrocious, both from a completeness and pedagogical viewpoint. Pyhton is again the ideal to aspire to.
But the point of the article stands: It is easy to write fast julia code, and the Julia (non-C/C++) parts of the Julia core form a nice tutorial for how "good" julia code looks like. If a function is not well-documented, look at the source code. In python, you quickly run into the C-wall (function is really implemented in C and the way the wrappers work is really non-uniform); in julia this is more rare, and the wrappers tend to be much easier to pierce (ok, julia does a ccall, figure out the code of the target; the wrappers are human-generated and readable and don't come out of a complex build environment).
But yeah, you shouldn't use julia for systems programming until a good standard way for unmanaged code has been fixed, if ever (mixing types that are garbage-collected and types that are programmer-memory-managed, you want garbage-collected types for performance-irrelevant parts and programmer-managed types whenever precise memory alignment matters for your performance). Oh, and the nullpointer support sucks big time.
My personal hope is that the python->julia interface improves. Then python users will be able to profit from fast, easily developed julia packages.