WAFs are a manifestation of Conway's Law: The people responsible for securing the company's web presence are not in general the same as the people implementing

WAFs are a manifestation of Conway's Law: The people responsible for securing the company's web presence are not in general the same as the people implementing the web request. When some API has some security issue, the securing team needs some mechanism to handle the issue faster than the API can be fixed. With that specification, you pretty much end up with a WAF, once you've been around the design space a few dozen times to refine the final product. If you are not a large corporation it may seem silly, but as the corporations scale up they become simply a necessity. If you like, call it "non-technical reasons", but it doesn't change their necessity. WAFs do things like securing an API written years ago by people no longer at the company, that for legal reasons can not be "just" modified or taken down, but which also can't be left with an arbitrary code execution vulnerability in it. By all means when possible fix the real underlying vulnerabilities, but at scale that gets to be easier said than done. In real life you may be arguing for weeks about whose "fault" it is, whose responsibility it is, whether it is even a bug or a real issue, and in the meantime, the company wants some ability to deal with this.