We use PGP for almost everything and it's so infeasible to bruteforce that it's considered secure. This is the guiding principle beyond CryptoLocker. But for stuff like e-mail, SSH and HTTPS, it's still considered secure even though the computational cost of encryption should be low since these are common tasks that have to happen millions of times a day. Now if an encrypted password with strong encryption is out in the open the attacker can't do nothing to it. But a hashed password is vulnerable - it can be bruteforced. So is there a password policy that can make encryption of a password with strong encryption secure? Can a user use his PGP keys to encrypt the password before sending it to the server? What about end-to-end encryption?
Properly hashed passwords
Web app stores the salt and result hash and iteration count (PBKDF2/BCrypt/SCrypt, crypto random salt, high iterations/work factor).
To log in, user enters password
web app retrieves salt and iteration count and result hash
web app hashes entered password with salt and iteration count, compares result. If same, is OK.
an offline attacker with a copy of the database can AT BEST get only those passwords that the attacker guesses
Said offline attacker gains NO ADVANTAGE if they steal the web app executable code also
Said offline attacker gains NO ADVANTAGE if they steal the web app source code also
Said offline attacker gains MINIMAL ADVANTAGE if they steal every other piece of data the web app can access, since they'll be able to use names, family member data, addresses, etc. to help guess passwords for people who use those to construct their passwords.
Properly encrypted passwords
Web app stores the IV and result encrypted PW in DB, and key in some other key storage (AES/Camellia/Aria).
To log in, user enters password
web app retrieves IV and key and encrypted PW
web app decrypts encrypted PW with IV and key, compares result. If same, is OK.
an offline attacker with a copy of the database of IVs and encrypted PWs can AT BEST get only those passwords that the attacker guesses the key for
Said offline attacker gains POSSIBLE 100% OF ALL PASSWORDS DECRYPTED if they steal the web app executable code also, if that's where the keys were
Said offline attacker gains POSSIBLE 100% OF ALL PASSWORDS DECRYPTED if they steal the web app source code also, if that's where the keys were
Said offline attacker gains GUARANTEED 100% OF ALL PASSWORDS DECRYPTED if they steal every other piece of data the web app can access, since the web app had to have access to the keys
Other major points:
Encryption means anyone with access to the keys, IVs, and encrypted passwords can silently and without trace impersonate any user, there or from the outside, which is generally considered horrifically bad.
Hashing renders the strongest cryptographically random, 30+ character passwords virtually immune from being guessed, because they are crypto random with a huge keyspace.
- On the other hand, encryption renders all passwords equally weak, no matter how strong the actual password is, because all you need is IV and key, and you get back even the strongest password to try on other sites or sell.
If you were already going to store encryption keys separately from the actual encrypted passwords, you can obtain superior results in every category by storing the per-user, cryptographically random unique salts separately from the actual hashed passwords.
The core issue with encryption of passwords is not that the encryption can be broken, but that someone with the decryption key can work out what the password is.
Imagine this scenario I start up a web service of some kind and I encrypt the passwords with 256-bit AES encryption and for the sake of an argument let's assume it's implemented perfectly, there are no flaws or side channel attacks, the only way to recover the password is with the key.
So you come and sign up to my service and put in your email address and set your password.
Now I go rogue, or maybe it's an employee who has/had legitimate access to the key, or maybe a hacker who dumped the database also stole the key. Whatever it is, the point is that somehow the key gets out.
Now anyone with the key can see that your email is firstname.lastname@example.org and the password you have used is "0pen 5esame" so now I go off to facebook, twitter, instagram and so on trying that email and password.
Now if we imagine the same situation but with PBKDF2 instead of AES there is now no key to leak, and while it can be brute forced it will take days or weeks to crack just a few weak passwords. There is no way to decrypt all the passwords at once.
 it could be argued that the user shouldn't reuse passwords across sites but this is the world we live in, and most people only have one password that they use everywhere.
In addition to the good answers here, I also want to say your statement "But a hashed password is vulnerable - it can be bruteforced" is quite wrong as well.
Bruteforce, or better using rainbow tables, is only useful for weak passwords. If you generate a random strong password with enough entropy, its hash probably won't appear in any rainbow table (nor can it be bruteforced in any practical time).
Older algorithms (MD5, SHA1) may have weakness for collision, but as it is a vector that is actively defended against in the design, it is unlikely it will give you too significant advantage in bruteforcing a specific hash (only in rainbow table generation really).