Do not restrict yourself by only analyzing the attack from outside. You have to see the bigger picture... think of security measures as layers of an onion. You stack as many as you can in the hope to close off any angle of attack. Password hashes are one of those layers.
Is hacking a database that easy? I mean instead of finding new ways to hash, why can't they make their database more secure or "hack-proof"?
It does not matter whatsoever how hard it is to hack the database. Consider that password hashing is supposed to protect the password from even the system or DB administrator.
Note that even if you would try to do so, it is not necessarily easy to protect the password database. How would you protect it? With another password? Where would you store that master password? How would you protect the master password against someone being able to read everything on the system?
If a hacker manages to hack into some database, why would he want to know the hashed passwords?
Well, to try and attack them.
Note how passwords are used: the legitimate user hands a username and a cleartext password to your login screen, the cleartext is then hashed and compared to the password hash.
Every attacker can do exactly the same, except doing it over the actual login screen/prompt is inefficient - it takes time and is easily detected; many systems will lock an account after a few bad attempts.
So when the attacker gets the list of password hashes, he can do the same hashing in his own program - blindingly fast, and especially with "dicitonary" or "rainbow" attacks, which trade RAM/storage against time.
So, shouldn't all the fields be hashed?
You cannot hash all fields because your application needs to know the value of the other fields, simply. It is hard to get the value back from a hashed version, even for a legitimate user.
But in fact, there are databases which do something like that - they encrypt (not hash) the actual data as well. You want to weigh whether it is worth it from a performance point of view, and you then have to make sure the encryption actually provides any real security. I.e., you have to make sure your key stays protected while the DB needs to have access to it, and so on.
Encryption is not appropriate for passwords because we actually do not want the passwords to be able to be decrypted (same ideas as at the beginning => inside jobs, and the difficulty to make the encryption key more secure than the actual passwords you wanted to secure in the first place).