Anyone that has application level access to your servers can still get your password very easily, for example every time you log in. Why is having a means to decrypt the password so much worse?
You misunderstand the point of password hashing, it is not about preventing people from breaking into the machine containing the hashes, it is about limiting the damage they can do with millions of passwords as a result of doing so. Most people do not bother to change their password from service to service, login to login. So instead of a breech on one system, you potentially have a breech on thousands.
Not if you are doing your login correctly. You shouldn't need to send passwords to a server to login, just hashes of passwords. That's the point. If your server ever needs to see a real password after the account is created or the password is updated, you have introduced a new vector of attack.
Done correctly, login is an exchange of hashes, not encrypted passwords.
A simple way to do this would be to send a unique, random salt S for every login, and the user would reply with e.g. sha1(password + S). However, to be able to check that the answer is correct, you would need to know the user's password, in plain text, which brings you back to square one.
To securely do this, you would need commutative hashing functions, i.e. hashing functions f(x) and g(x) such that f(g(x)) = g(f(x)). Actually, to be completely safe, you would need to be able to generate a whole (preferably infinite) family of commutative hash functions g(x), a random one for each login. I have no idea if such functions exist, more importantly, if they are known, it's an interesting idea actually.
In most cases, anyone that has application level access can already do the things an ordinary user needs authentication for. The password is irrelevant, unless you want to find it out to access another system you don't already have permissions for.