Question: The new place I started at is just starting to develop a completely new product from scratch. They are going transaction script in application services, completely dumb entities, and a hand rolled DAL with stored procedures (the argument is that nhibernate doesn't optimize sql well, loads too much stuff, doesn't scale well to huge projects etc etc etc). the app is supposed to be HUGE project just in it's infancy.

I'm coming from a position where I was doing domain model with all business logic encapsulated in that and the app services only handling infrastructure + loading up the model with nhibernate and scripting it.

I really believe going with the 2nd approach is much better. I was planning on doing a presentation on why. I have plenty of books/articles/personal opinions that I can back this up with...but being more of a "junior" there it might not mean much (I was also the single dev at my last place).

What I'm looking for is some experience/tips/examples of failed projects from more senior people why going transaction script/hand rolled DAL is not the right idea.

Answer: 
Well there is always two sides of a coin. 
They may have some points regarding Nhibernate and performance issues. But there is always solutions to that, like load strategies where you tell exactly how Nhibernate should tackle specific critial queries. 
With load strategies, caching and sql index tuning you can get far regarding performance, really far.
But true benefit with ORM is that it reduces code base and make it more DRY. Makes your system more maintainable. It also reduces a "layer" since you do not need stored procedures. 

I've been in several projects like you, and trust me, they face mainaince problem with
 \* probably redundant code in application services since you do not have a domain core that can put logic at one place instead of appearing in several application services methods.

* A huge DAL layer that includes several Stored procedures.
* Logic easily slips out to GUI

I can make the list longer... but my point is that people tend to choose Transaction script sometimes just because it easy to understand, to start with and, well can be good at performance.
BUT usually the problems occur when consultants, employees leave project and maintanence team takes over. There is often not cristal clear where changes should be done and most TS application I've seen has been architectural abused. They were good apps from the begining but since the invite you to put logic in SP's, services, GUI (because of the lack of restricted API, interfaces etc).

You follow me?
/Magnus

p.s You can get great performance and DDD with CQRS approach...
I would say taking material to back it up is the way to go, that way they can't use your inexperience as an argument (although it sounds to me that you are not particularly inexperienced or junior!). My main reccomendation would be this book:

<http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&qid=1317121019&sr=8-1>

On page 146, it states: 

'TS is suited for simple scenarios where the business logic is straightforward and, better yet, not likely to change and evolve.'

This does not describe the system you are working on. 

It then goes on to describe Domain Model, and why it is suited to bigger systems.

I would question whether thay understand that it is Transaction Script they are opting for? In my experience, TS can often be the default choice for inexperienced organisations who don't even understand that there is even an option. They just think 'that's how it's done'. How successful and maintainable is their current code? If they are choosing TS for huge projects, my guess would be 'not very'! Do they blame the client for changing specifications when things go wrong? If so, this is an indication that their choice of architecture is wrong.

In my experience, the overhead in implementing Domain Model is minimal. And it is a lot less painful than trying to scale and maintain a badly architected system.

Also, in this day and age, database servers should be able to handle systems based around NHibernate with no problems. If it can't, then that is a problem with the database server. And how do they intend to unit test these stored procedures? I usually find SP are the single biggest point of developer error.

Like Magnus said, I could just go on and on about this. I don't know the details of the system, but as soon as you used the word HUGE, Domain Model becomes the most obvious choice.