What is bad in revealing the password hash-and-salt is that it allows offline dictionary attacks: since the password hash and the salt are sufficient to verify a potential password, then, by definition, they allow an attacker to try passwords on his own machines, limited only by the number of PC (or other hardware) he can muster. This contrasts with online dictionary attacks, where each try must go through your server, and your server will not accept to try billions of passwords per second.
Password hashing is a second line of defence. You don't want attackers to obtain enough information to run offline dictionary attacks; but when they do, you at least prefer it if they have to pay the full price of the attack, i.e. you show them only password hashes, not the passwords themselves. Plus, you want a slow hash function (with millions of iterations), and the salt to prevent parallel attacks and other similar optimizations (like precomputed tables).
All of this is about protection of passwords, as in "secret data that human users remember". Human brains being what they are, passwords tend to be vulnerable to dictionary attacks. However, if you can convince your human users to remember sequences of 20 random letters (not sequences that they choose themselves, but randomly generated letters), then you can show the hash values, because sufficiently random passwords are out of reach of dictionary attacks anyway -- arguably, these are no longer passwords but keys. Note that this is not a matter of length but of randomness: a password is not strong because it is long, but because it was produced with enough randomness in it; you just need length to make room for randomness.
If you need a reference to smite unbelievers, then invoke NIST Special Publication SP 800-118 (still in draft form, but published nonetheless), which notably includes this quote (from the "executive summary"):
cracking attacks can be mitigated by using strong
passwords, choosing strong cryptographic algorithms
and implementations for password hashing, and protecting the confidentiality of password hashes.
(Emphasis is mine.)
Password hashing is a difficult art. You say that you use "HMAC/SHA-1", but HMAC is not a hash function; it is a MAC algorithm. MAC algorithms use a key. What you probably mean is that you use a password hashing function which has been designed over one or several invocations of HMAC/SHA-1 as a building block. PBKDF2 is such a password hashing function. It includes an extra parameter which is the number of iterations and that's an important one.
See this answer for a detailed discussion on password hashing, its theory and its practice.