Some webappsec scanners are actually slower than one user using one XP-based web browser.
If Burp Suite Pro Intruder (or Scanner or Spider) is tweaked to over 100 threads, say 175 threads, then things start to fall down, but usually the memory of the target servers before load balancers or firewalls in-between. The max used to be 175 threads but changed to 999 threads in 2014.
Some software-based firewalls will fall under the load of an extremely-cruelly tweaked webappsec scanner, but not appliances or hardware-based ones. For example, a Palo PA-3020 will still push traffic to destinations if you had 20 or even 30 penetration testers using webappsec scanners. However, a Palo VM-100 might only fall to 2 or 3 penetration testers because it's mostly software-based.
WebInspect, AppScan, and Acunetix are nicer than Burp Suite Pro Intruder's maximum configuration (e.g., WebInspect only allows a max of 80 concurrent threads). Even when I tweaked these other scanners to max threads supported by their configuration, the worst that has ever happened was that a web server or two would lock up. Never had a WAF, IPS, or load balancer lock up in that same way. Pretend this has happened to me ten times in my life and that half of the time one web server locked up and the other half of the time two web servers locked up. Every time, no matter how many web servers locked up -- the root cause of failure was due to the web server only having 256M, 512M, or 768M of vDRAM. In every instance these were guest OSes of a server-virtualization based hypervisor or a shared-hosting environment. It was simple enough to ask the far-end IT System Administrator to shutdown the server, give it some more vDRAM (usually 1G was enough), and start it back up.
Usually the best way to determine if there is a problem is to host your pen-test infrastructure (your attacking hosts) with a gateway running Linux. Then, you can leverage ntop or tcptrace to look for retransmissions. If you're not getting any retransmissions, or a very-small amount, then no harm, no foul. Sometimes you will see tools abbreviate retransmissions as retrans, rexmit, or rexmt. Check out the book, TCP/IP Illustrated, Volume I: The Protocols, Second Edition for more information about the inter workings of TCP.