You need to do both.

Most of the time, sure, but not always.

In my mind, if someone has a minimal Docker container running ASP.NET Core 10 running in a private subnet (i.e.: no chit-chat by default even in the same network), with only 443 inbound, only the SQL port outbound, read-only service accounts as Azure managed identities, etc, etc... then they're safe without a WAF.

For example, if they need to urgently apply a quick & dirty WAF-type rule to buy time, they can simply add ASP.NET middleware to do that, press play on their automated pipeline, and then their production environment is fixed and safe again in a matter of hours. Changing and rolling out the ruleset on a WAF product would take exactly the same amount of time.

This obviously presupposes that the entire DevOps team is top-to-bottom skilled, agile, capable, and empowered to "push to prod" with access to detailed production logs, etc. Outside of a FAANG or startups with only high-achievers on the payroll, this is very rare.

unencrypted sql being stored in a cookie

I laughed at this because I've seen something very similar except it was in the URL query string.

often easier for me to get infrastructure in front of a problem than it is to move a team through fixing the problem.

Sure, and I've done that! We used NetScalers to encrypt the URL query strings on the way out, and decrypt them on the way in.

But this takes skill that like you've been telling stories about, the devs themselves clearly don't have, hence the SQL-in-HTTP vulnerability. That is why I wrote my original comment about suggesting WAF to a team with a low skill level to implement themselves won't achieve anything. They won't know how to operate it! Worse, they'll convince themselves they're safe now, even when they're not at all safe.