In your OP you asked for an instance when using an ORM is "bad". I wouldn't go so far as to say ORM is bad, but it has consequences, not all of which are good.
- ORM's generally follow the Active Record pattern* (because Data Mapper is a bit tricky)
- this tends to impose design decisions on the database that favour application code
Here's a great quote from an article by Bill Karwin that sums up why this may not be such a great pattern (I couldn't find the thread on SO where it's referenced...): http://karwin.blogspot.com/2008/05/activerecord-does-not-suck.html
A single Model class may be backed by a database table, or multiple
database tables, or perhaps even no database tables. Data persistence
should be an internal implementation detail within a Model; the
external API of the Model class should reflect its logical OO
requirements, not the physical database structure.
With regards to "DAL", this is a deceptively simple acronym that encompasses a range of patterns. Personally I prefer using query generators like Zend_DB or NotORM, and writing custom methods to describe the relationships as and when I need to. It takes a bit more hand cranking, but you get intimate with the Domain Model (as opposed to the ORM Model...) and the database that supports it.
There are a couple of classic books on this subject that are well worth a read if you can track them down:
Data Access Patterns : Clifton Nock
Handbook of Relational Database Design
As an aside, it seems somewhat tragic to abandon RDBMS design and the SQL to interrogate it to the application layer! It may not be the new thing on the block, but it's a remarkable bit of technology expressing some very refined concepts that are arguably more robust than the short term design phase that will be applied to the immediate needs of a project. I've seen way too many apps that leave integrity constraints in the application layer, or fail to take into account the indexing/querying methods employed by the DB platform they are using. ORMs are undoubtedly a clever bit of kit, but so is SQL...
Here's another great quote on the subject that expresses this sentiment (with reference to the Table Module pattern:
In many ways this approach treats the relational database like a crazy
aunt who's shut up in an attic and whom nobody wants to talk about
and here is another thread on SO that is very pertinent to this subject:
Constraints in a relational databases - Why not remove them completely?