If the key is embedded in the app and you don't keep the source on the server, reversing the binary (if the attacker even thinks to steal it) is enough of a hassle to deter most people. And maybe the attack only allowed them to copy the database.
It's not foolproof, but for stupid free websites (that's what we're talking about right?), storing encrypted passwords isn't an automatic gimme for the attacker.
It's a pernicious myth that passwords on "free" websites don't matter, because no money is changing hands. Most people use the same password for random apps as they do for their email account.
I don't even want to get into the rat-trap of "what kinds" of attackers are stopped by reversably encrypted passwords. There's no kind of attacker that can reverse a properly hashed password, and so that's what you should use.
Why, oh why, do any websites need to be able to reverse an encrypted password to the plaintext? 99.99% of the time, simply resetting the password to something different is a much better way to go (in the case the user forgets).
I'm sure there are exceptions to this rule, but we shouldn't encourage a design that has the potential to hurt users (if the database + password encryption key are compromised), when the solution (seeded hashing) takes just about the same amount of work (probably less).
It's not foolproof, but for stupid free websites (that's what we're talking about right?), storing encrypted passwords isn't an automatic gimme for the attacker.