Tricky question so I'll ask one in return, what "arena" is your client in? E.g., government, financial, telecomm, etc. For example, government has OVAL (http://oval.mitre.org/adoption/productlist.html) which documents "approved" and or "used" tools. This limits the potential of something going wrong however, it will never and CAN NEVER constitute a real world simulation.

In the real world, an attacker will use whatever is at their disposal. They won't care if their tool crashes a system or hangs a port. This does not mean you should follow suit, on the contrary, this means you should finesse things to be able to use the same types of tools in a responsible fashion. Getting your client to understand this is key though.

My goal in a situation like this would be to supply them with a "by the way" report of these would be the tools you would LIKE to use. Giving them supporting documentation on why you would use this tool, how you would use this tool, the benefits of testing with the tool and so on.

Problematic to the tester are constraints. You will never truly know the vulnerabilities of a network unless you 1) find them 2) exploit them. Otherwise your report will be a "white glove" report of inconsistencies. Iterate this to your client in a professional manner and make a business case for them as to "why" you would prefer to use an alternative tool not necessarily "sanctioned" by them. You may be surprised at their response.