In addition to the "right tool in the right hands" comment I should like to add that you should make sure that you are using the right tool for the right reason.

If the tool is being used to get around a break down in the relationship between the DBAs and the development community then things have gone badly wrong and will get worse fast. DBAs and the development community have to work together. Remember, the competition are the companies who compete with your company, not your internal structures.

The competition will love it if all they've got to do is watch you fight amongst yourselves so all they have to do is go in and bayonet the wounded!

nHibernate can use stored procs just as it can use direct table/view access. The whole point of these tools is to separate out the needs of the object layer from the needs of the relational layer. Obviously there is some cost to doing this because nothing is for free but when developed in sympathy with each paradigm a great deal can be achieved.

ORM tools seem to be good at prototyping and greenfield development but are the polish on the poo of a brown field development.

As applications become ever more open it is more vital than ever that the data layer is secure.

This Sunday there was an article in the papers about 19 companies being shut down in the UK due to data protection violations. These weren't bugs, these were violations of the data protection act. Every piece of data needs to be categorised to determine what security access is appropriate and to what roles. Again, getting the ORM tool set up appropriately is extremely important so you don't accidentally expose your data.