I think your example just shows that their tool is making some assumptions about decoding, based on the input given.
In a true real-world case, you would not know how complex the user's password is, so you have to assume it can contain any of the ~90 printable characters (a-z, A-Z, 0-9, ~-/) in any combination. This would make "complexitya" and "C0mpl3xityA" statistically identical, but time to crack would depend on how you approached it (do all 1-character combinations, then all 2-character combinations, etc., or fully random, or increment through dictionary words, common letter/number substitutions, and so forth).
If we know things about the system, like it will allow an alphabet-only password of all lower case characters you could make assumptions that let you greatly speed up cracking the password.
It would also depend on if we were trying to find a specific password (ex: the root password from the Sony backdoor) vs. crack a bunch of hashes to create a rainbow table. For the Sony password case, we do not know anything about the password length or complexity, so we would have to try every option. If we had a dump of hashed user passwords, we could probably decode the majority of them relatively quickly, but long/complex outliers would take significantly longer.
If we knew the site that a dump was procured from enforced rules like "must have at least 1 upper case character and 1 special character" we could crack that FASTER, because you can eliminate trying all combinations that did not meet those requirements.
In general, pure dictionary words are bad, but I personally think that "Complexityhij" (a slightly modified dictionary word) would take more time for the average attacker to crack than "$Fj*b1" (a highly complex password) if all they had to go on was a set of hashed password data.