I disagree with the accepted answer. It's true that the password length is nearly useless if all passwords are randomly created by a machine. This no longer holds if passwords are created by humans in the usual way: Based on one or more dictionary words, mix upper case lower case, substitute some characters with numbers or special characters, and add prefixes and suffixes (e.g. "!1"), etc.
Let's look at 2 scenarios, one is we have 10'000'000 passwords hashes and want to find as many matching passwords for these hashes as possible. The other is one password hash and we want to crack it. In both scenarios the difference turns out to be significant. As usual, all information can be abused in an attack, even if it doesn't seem so at first sight.
Scenario 1: Crack many out of 10'000'000 password hashes with limited resources.
We can just try bruteforce attacks on all of the password hashes with no way of distinguishing them if we don't know the password length.
If we use an exhaustive bruteforce attack (which is guaranteed to find the password) knowing the password lengths will only offer a very minimal gain. Why? Bruteforcing all 7 digit passwords takes about 1-2% as long as brute forcing all 8 digit passwords. The only thing we gain by knowing the length is that we don't need to brute force all 7 digit (and smaller) passwords if we already know that the password has 8 digits. Except that a bruteforce attack requires near infinite resources (computational power and/or time) and therefore isn't something we can or will do.
Instead we test a series of "likely" passwords for each password length. One way to do this is with a dictionary attack. Testing likely passwords is several orders of magnitude cheaper than using exhaustive brute force, but it has a huge disadvantage: Once we've tried all "likely" 7 digit passwords against a password hash, yet did not find the matching password, we do not know if the matching password for this password hash is longer than 7 digits. So unless we know for sure the password is not longer than 7 digits, we still have to test that password hash against all "likely" 8 digit passwords, 9 digit passwords, 10 digit passwords, etc - and when testing likely passwords, just like exhaustive bruteforce, the cost of testing longer passwords increases exponentially. Since we now know the password is 7 digits long, we don't have to test it against likely 8, 9, 10, 11, 12 digit and even longer passwords, saving a truly massive amount of work.
It gets better. Once we tested all likely passwords up to a length of, say, 20 digits, we can now spend our remaining resources on a brute force attack on those password hashes with a small password length which our previous search for "likely" passwords did not crack. Say we have 2'000'000 uncracked password hashes remaining and 100'000 of these have passwords with less than 6 digits. Keep in mind we have a limited budget. 6 digit passwords are cheap to crack. But because we know which 100'000 are 6 digit or smaller, we now need to brute force 100'000 6 digit passwords in order to crack 100'000, instead of brute forcing 2'000'000 passwords to crack 100'000 6 digit passwords. That's 5% of the work for the same result!
If we look at all the benefits combined, the exact gain we receive from knowing the password lengths depends on the speed of our method to test "likely" passwords, the respective success rate of our method to test likely passwords for each password length, the distribution of password lengths in the password hash collection we want to crack, and the amount of resources we have available (calculation speed, time). But by knowing the lengths of the passwords we can easily increase the number of passwords we find with a given amount of resources several times over - if the numbers work strongly in our favor, we can possibly reduce the resource cost to crack 30% of the passwords by an order of magnitude or more.
Scenario 2: Crack a single password in a targeted attack
Not knowing the length of the password, we need to distribute our resources between brute forcing all keys with a short length and testing likely passwords with a longer length. Assuming we spend half our resources on each, knowing the password length allows us to completely pass on one of the 2 and therefore double our available resources.
We also gain additional information which can be extremely valuable in a targeted attack:
If the password is short enough to brute force it, we can give an upper bound on how long it takes us to get the password. This can cause us to attempt some attacks we otherwise wouldn't even consider.
We also can calculate a likelihood of cracking the password at all. If we know we are unlikely to crack the password we can spend our resources on finding other ways to compromise the system.
If we have 2 different passwords from the same user we can see if there is a chance they are actually the same password. If they vary by only 2-3 digits we can make an educated guess that the longer password might be the same as the shorter one, plus a prefix or suffix.
If we gain even more info about the password, it may result in a gain that is a lot more than the 2 pieces individually. For example if we find out the password is a single word from the Oxford dictionary, you still have a chance to keep the password safe if for example we can only brute force one password per minute. But if we also know the password length is 17 digits, it's game over.