What's the point of stealing hashed passwords?
Let's say I steal a hashed password, I can take a random string, hash it, and see if the hashes match. If they do then I've just cracked your password.
For example, assume that under some hash function we get the following hash table:
"cat" --> AA
"dog" --> AB
"elephant" --> AC
If I steal a password database and see that your hashed password is
AB then I know that the plaintext password is "dog". (technically, more than one string will hash to "AB", but since the server is comparing hashes, not raw passwords, any of them will let me in. So in effect your account has multiple passwords; any string which hashes to "AB" is a valid password for your account.).
Attackers can crack hashed passwords by pre-computing hashes for large numbers of potential passwords (usually obtained by combining dictionary words, or from lists of previously cracked passwords), and then using this as a lookup table to convert hashes back into plaintext passwords.
This kind of attack is generically referred to as a Rainbow Table Attack, with introductory explanations here and here.
One issue with rainbow tables is that to cover any reasonable number of candidate passwords, the size of this lookup table grows to terabytes and requires multiple hard drives just to store it. As you can imagine, attackers have developed fancy tricks for optimizing the reverse-hashing process, so while the general idea of rainbow tables is simple, actual optimized implementations get very complicated very quickly.
It's worth mentioning a few of the common counter-measures that db admins and developers use against rainbow table attacks.
salting is the trick of appending a random string (the 'salt') to the raw password before hashing it. Each user has a unique salt which means that, in effect, each user uses their own unique hash function, so an attacker can't re-use rainbow tables and has to pre-compute a brand new table for each user.
Take the password and run it through a large number of salt-and-hash iterations of a strong cryptographic hash function before storing it in the db (for example, 100,000 iterations of SHA-2), which makes it much more expensive to pre-compute the rainbow tables. It also makes it slower for users to log in.
Use a hash function which takes in a private key (these hash functions are called HMACs). The idea is to use a private-key known only to the server in computing the hashes so that it's impossible to compute a rainbow table without knowing the key. The problem with this is that when an attacker has enough access to steal a whole database, they can usually steal the private key as well.
In your question you also mention storing encrypted passwords. This is similar to 3. in that, unless you have a good way to protect the encryption key (for example, dedicated hardware like an HSM), then the attacker will steal the key along with the database.