It kind of defeats the purpose of the pen test if they don't. Without exploits, how is that different than a vulnerability assessment? The purpose of a penetration test is to demonstrate the actual impact of a compromise, and you're significantly limiting the testers' ability to do that if you take exploitation off the table.

The DDoS analogy really isn't a fair one since that intentionally focuses on disrupting services with a very high likelihood of success. I've seen testers inadvertently take systems/devices/appliances offline with nmap, hydra, and MITM attacks. Should we take network scanning, password cracking, and ARP-poisoning off the table too? You know, just in case...

There's an enormous difference between someone coming in and running autopwn and someone carefully researching and executing a specific exploit. Someone inexperienced and reckless can cause problems regardless of the tools or techniques used. You also need to remember that fluke circumstances may cause problems regardless of the skill or experience of a tester. There is always going to be some inherent risk (then again, I've seen regular users do worse, so that risk may always be present).

An experienced tester/company will work with you to scope the engagement properly to help ensure the impact of such incidents is kept to a minimum. For example, critical systems may be tested after hours, or their test/QA equivalents may be tested instead. This starts to deviate from a "true" penetration test, but it's often necessary to balance business and security requirements. On the other hand, if such a DoS condition exists, when would you prefer to learn about it? It's extremely unlikely that a tester would be the sole person capable of triggering it.

Regarding your Domino server, what value would the deliverable have had if they didn't? Why not just do a vulnerability scan and write, "This vulnerability could be leveraged to compromise the network," next to each finding? Seeing is believing and an actual results seem to get stronger executive attention and support for remediation.

My answer will likely annoy some so I will explain it as best as possible. When it comes to buffer overflows and outright full blown exploitation, it really depends. If there is a mechanism I can use to validate that a specific vulnerability is exploitable, I will offer the proof while trying not to exploit it and leave the option to the client of going that distance to the client. There is a separation here which is going to catch someone reading this off guard:

When I perform a penetration test for a client, my goal is to get in, out, family jewels. Bottom line. I am not there to perform free security testing (fuzzing, reversing) for Cisco, or Microsoft, nor whatever other product my client is using. This is what recon, research and prototype labs are for.

Suppose I am testing a "known to be vulnerable/exploitable" version of say Coffee 2.0. I can try to see whether or not I can obtain my own copy of the same exact version my client is running, exploit my own and offer it as a result: "I exploited Coffee 2.0 in my lab which is similar to your Coffee 2.0" and then work with their staff to match any differences. Sometimes a Proof of Concept is enough.

Now, when you state that pentesters are hellbent to get root at all costs, I beg to differ. Getting root or administrator access is 3rd on my list when I perform penetration. My first goal is to get into an environment period. That alone is cause for concern as there is the possibility that if I got that far, I will get further. My second concern is getting data, and I don't always need to be root/admin to do so. I can compromise an SA/DBA account and still have the same impact. If I can, by all means I will go the distance to get root, but most times, getting in, getting data is enough, showing the passwords/accounts of other users is often enough.

Too many individuals aiming that high (3y3 h4v3 r00t) leave a lot to be desired in a penetration test and need to gain a lot more experience in the real world. So think about this for a minute:

HellbentOnRoot Pentester: "We were unable to obtain root access. Seal of approval your safe"

Experienced Pentester: "After getting into your infrastructure, I was unable to gain root but I did manage to use  the credentials of a DBA account and obtain a list of your clients, partners, and employees. I decided not to exploit a known to be vulnerable version of Coffee 2.0 since I had obtained the family jewels however, Coffee 2.0 has known holes which attackers are known to have exploited and in my pilot lab, I was able to exploit it. Here are the references to the exploit and here is a video demonstration of me exploiting it in my lab."

At the end of the day though, it all boils down to the SOW between the tester and the client. In many high end environments, I have done testing on failovers and backup systems as they were exact copies of the running environments. I did so to avoid taking out mission critical equipment yielding the needed results. I have yet to crash anything on a client's network and this is because there is a set of exploits I know will crash a particular, so I avoid them at all costs. Most of the times, I don't even need them. That's just me though.