In this post, Ayende talks about when we should use NHibernate and he points out that in almost any read only scenario, another approach can be preferred. I think he forgot to mention the fact that even in such a scenario, we can leverage a very reliable multi DB abstraction offered by NH that can help us if we think of targeting different data platforms.
According to me, we should say that the point of decision to choose from NH to another approach is the ability to create an entity model, and an entity model helpful to our objectives. This can also depend on how much we are comfortable with the technology. Another interesting extension of the argument is, if we should not use NH, what can we use instead? Well not for sure EF, since the reason of renouncing to NH in a project should be the same to avoid EF. The NOSql solutions work only if we can completely avoid a relational database, and the pure crude ADO.NET is just ugly. An option could be Dapper, a lightweight OR/M (not exactly an OR/M, but almost) that removes all the ugliness of ADO.NET and does not change the performance in comparison on using the manual data access approach. I did not try it myself, but one of its users is stackoverflow, so this should be by itself a guarantee.
