I agree with @mice here. He isn't talking about storing the passed hash, but a sha256 hash of it. Using heavy hash functions, versus lighter hashes, reduces the random password length required for the same security against brute force cracking.

Yes, if you could reverse hash the sha256 hash stored on the server to the 'random' 32 byte binary output of the heavy hash, you could use that as the password, but that isn't feasible with current technology. The alternative would be to start with the actual password candidates and calculate both the heavy hash and the sha256 hash a gazillion times until you find the one that produces the stored hash. This could be feasible if the password is weak, but that wouldn't be the fault of the system.

In short, I see nothing wrong with this idea if implemented correctly, and sufficiently strong passwords are chosen. In practice though, it only allows you to shorten password by a couple of characters for equivalent security, so is it worth it?