It's interesting. The author shows some fundamental misunderstandings and makes assumptions that are not necessarily based on real-world situations to present an idea that longer strings with more recognisable characters (e.g. passphrases) are better than shorter strings with larger keyspaces. If you pick two data points you can actually fiddle with the numbers to present either side of the argument as the truth. For example:

A full 16-bit unicode 2 character password has 65 536^2 or 4,294,967,296 permutations to work through.

A lowercase alphabetic password of 6 characters in length has 26^6 = 308,915,776 permutations.

Of course there's a tradeoff involved, and that tradeoff is what IT departments try to manage, with mixed success. It's easier for the software to determine whether or not the password contains methods of increasing the keyspace than whether or not the user has typed out a 200 character long series of 'A' characters, so that's what they use. I don't know whether or not increased length has a higher risk of collisions for some algorithms (that's tptacek territory, not mine). Over time, software products have been guided by best practice standards from organisations like COBIT that define and mandate complex passwords based on keyspace rather than length alone.

Secondly, there is a difference between an online brute force and an offline brute force. Depending on the algorithm, with the right kit (or Amazon EC2 instances) you can get billions of hashes per second to crack a password hash offline. At that point your increased length only matters if the attacker doesn't know about the complexity. The samples provided are terrible as they're all lower case with a space at most. This is the poor end of the trade-off. To brute force a SHA-1 hash of the word 'sum' on my 2 year old laptop takes less than a second.

Online brute forcing (e.g. brute forcing a web form) is generally something you're not going to do if you're looking to compromise a web account, unless it is a specifically targeted attack (e.g. the user is an admin or a specific person of interest). In these situations your brute force rate is dependent on your network throughput, the application's ability to respond to concurrent requests and any other factors that may affect it (such as any monitoring system). Your web application on a linode slice will probably choke out between 40 and a hundred attempts per second (and you'll notice it unless you're blind or have no performance reporting). If you can get past the automation detection in larger sites, like Amazon, Google, Twitter etc. you'll probably be able to go much, much higher. For this reason, web site brute forces tend to be dictionary based, or at most on dictionaries and a number.

Ultimately when choosing a password you need to consider what you're defending against. If you own the box or the app, chances are you trust the defences. If you're going to change the password every few months then maybe you will choose a weaker password. If you don't own the kit and you're not intending to use the password, then use a tool such as Keepass[1] and generate the passwords yourself. That way it doesn't matter what J Arthur Random says on the Internet, you won't need to remember the passwords at all.

[1] - http://keepass.info/