While I completely agree with you that the attacker getting into the database is an issue in the first place, "what is false" is that this is an excuse to divert the problem from blatant lack of understanding of basic principles in security.

My way of seeing this (and you might have a different opinion, which I respect as well. I want it to be clear my comment wasn't a personal attack) is that I use a strong password that would not be easily crackable by dumb bruteforce or rainbow tables. Therefore even if an attacker breaks in to a service that I use, steals database tables containing hashed and salted passwords and gets cracking, the likelihood that he/she breaks MY password is relatively low. Now the minimal effort from the company providing the service went to great length to complement MY effort of choosing a strong password.

There are a lot of problems in security. Weak passwords and password reuse are the burden of the user. Correct storing of passwords and preventing intrusions are the burden of the developer. Neither of those are an excuse for skipping hashing and salting because "it can be broken easily". You mention 12 months yourself, I'm sure my bcrypt'd/salted 16 character non-dictionary word unique password would discourage any cracker (and take more than 12 months to crack) and all of that was a lot easier to set up than a dedicated password storage solution.

Point is, do whatever you can to protect data. Better safe than sorry.