Remember, this article is specifically about language choices for programming education.  I agree that Java is still the default choice for a risk-averse bureaucrat in industry, but in education, Python has become the most popular, default choice (that's sort of the whole point of the article).  In industry, many managers don't feel the need to look beyond Java to find more compelling options (even those that might boost productivity); similarly, at this point, many educators don't feel the need to look beyond Python to see if there are more compelling options (even those that might provide a better educational experience).

That's what I think the author's point is about Python being "blandly conventional".  There's no reason to think that Python is the pinnacle of educational languages.  It wasn't designed to be an educational language, so it should be possible to do better.  But it happens to be a pretty good choice for education, good enough that many people have stopped looking for better.

Ruby isn't mentioned because it never made significant waves in the educational community.  Remember, the article is just about educational language choices, not fashionable languages in general.

I think the best way to understand these criticisms is to take a look at the language Pyret (pyret.org), a language that is being developed by Shriram Krishnamurthi (one of the educators quoted in the article) as an answer to the problems he sees with Python as an educational language. 

In Python you have a couple options to build structured data.  You can use the object system, but that's a little heavyweight and clunky for beginners.  You can just use dictionaries with the relevant entries, but beginners often don't have the discipline to mentally keep track of many different types of objects that are all dictionaries with different combinations of entries.  This gets especially problematic when you get to recursive data structures like binary trees.  It's pretty tough to teach this well in Python with dictionaries, so teaching this usually gets delayed until the object system has been taught, and then all your functionality that operates on the trees are generally written as methods split between the branch and leaf classes.  This is tough for students because the code for a given function isn't all in one place, it is spread out among the two different types of classes.  Contrast this with Pyret's approach to structured data and recursive data structures.

As far as testing goes, Python's biggest limitation is that structured data created with dictionaries or objects are mutable data structures.  It is fundamentally more difficult to test mutable data structures because you can't use a built-in notion of structural equality.  So all tests must be in the form of setting up an object, calling functions/methods which mutate it, and then testing various properties of the mutated object.  This is onerous for beginners, and very hard to get them to do this with any kind of discipline.  Testing is radically more simple in languages that offer a rich set of immutable data structures and an easy way to create new immutable data structures that automatically come with a structural equality comparison.  So it's easier to teach a "tests first" approach by starting with immutable data structures and moving to mutable data structures after students are more mature in their programming experiences.  Doctests are great for regression testing, e.g., copying and pasting an interactive transcript into the actual code, but are not very easy for students to write the tests ahead of writing their code, especially for complex data structures or testing that certain errors are raised -- it is hard to figure out ahead of time how that kind of stuff is going to print.

I vastly prefer dynamic typing over static typing in my own code.  But this is about education.  We have a responsibility to teach students both, so a language that lets you gradually transition from dynamic typing to static typing is preferable (in education) to one that doesn't.