Regarding ORM and Hibernate, my company is currently using Hibernate 3.0.x (started with 2.x, soon to upgrade to 3.1.x) with our new Java-based web applications (migrating slowly from VB6 desktop apps). For simple CRUD (create, read, update, delete) operations, Hibernate makes the developer's job trivially easy to do. There is no need for developers to write any SQL in these cases. In fact, they shouldn't ever have to write SQL anymore, although Hibernate has its own query language called HQL that is an object-oriented variation of SQL that is useful to solve some issues.
Most of the problems that I've seen arise when you want to use Hibernate to do reporting, or ywhen ou run into performance problems because the developers don't fully understand what Hibernate is doing when it converts their configuration information and Java code into actual SQL. Hibernate is a lot more complex that it may look on the surface, and there are definitely best-practices that should be used and anti-patterns to avoid. It is also very flexible, though, and you will find that the developers have actually put a LOT of thought into the features and default behaviors of the tool.
Debugging performance issues can be very time-consuming until you have experience doing it, although Hibernate's "show_sql" feature can help a lot (along with profiling on the database). I highly recommend the "Hibernate in Action" book by Manning Publishing, whether you're a developer or a DBA.
My company is also practicing agile development methodology (yet another topic for another day), so in addition to using Hibernate, the developers actually "evolve" the database schema as they need to implement features. (I know, shudders just went through every DBA reading this!) It's not as bad as it seems, though. There are definitely some pitfalls that they've run into, but when our DBAs catch them, there has always been a way to fix the problem using the additional features that Hibernate provides.
I think a best-practice for us was to have a DBA work with (or even "pair" with) the development team part-time to prevent some of these issues. Learning to use Hibernate effectively (and efficiently) is definitely more of a journey than a destination for all parties involved.
I am interested to hear Don's arguments for using stored procedures since I like the idea of providing abstraction layers to the database (which Hibernate also does, but more from a developer's perspective).
Dave