• From what I've been seeing in recent years, the industry trend is moving away from using stored procedures.  This is not necessarily due to simple ignorance on how stored procedures work, but rather due to conditions in the business environment.

    Software vendors have an incentive to appeal to as many prospective customers as they can, and many of them have made the decision to try to support multiple database platforms.  One of our vendors, a well-known one, supports Oracle, SQL Server and (if I'm not mistaken) Informix, and they're hardly alone.  This means they have an incentive to write their SQL as generically as they possibly can so that it will run effectively on whatever database platform the customer prefers.  This means, among other things, eschewing stored procedures -- Oracle PL/SQL procedures are simply not interchangeble with T-SQL procedures, architecturally.  For one thing, Oracle procedures don't return results sets.  (At least they didn't do so four years ago, my last direct exposure to Oracle.)

    Our experience with vendors that support multiple databases is that they like to stick to straight SQL, and to keep that very simple -- preferring to do any extensive data manipulation in another tier.