<i>A poorly-written web app whose SQL database is compromised has bigger problems than protecting the integrity of poorly chosen passwords (especially if they store financial information).</i><p>Are you suggesting that because a comprise is bad, nothing should be done to reduce the magnitude of the impact?  This argument does not hold up in general, and it is especially weak when arguing about using encryption algorithms with freely available, high quality implementations.  The developer effort required to use bcrypt is minimal.<p>Also, you seem to be making the incorrect assumption that only poorly written web applications get their databases compromised.  Web applications with excellent security get their databases stolen for a variety of other reasons.  Even if the programmers do everything right, a careless employee might get his/her password sniffed or stolen by a key logger.  If a company uses external hosting, its database could get stolen because of a mistake by the hosting providers.<p>In summary, the risk of your database being stolen is always present, regardless of the diligence of the the programmers who implemented the web application.  The fact that a compromise is bad is not justification for ignoring simple security measures that take minimal effort to implement.