This article made zilcho sense to me. I kept waiting for the part where it was going to tell me what was wrong with webhooks, but when it actually did it felt like one of those "where did the soda go" things, with overly-complicated emphasis on things that aren't really problems. "The hidden cost of webhooks" section is basically just complaining that you need to run your own actual server, including "maintain the code". Even that is really overkill because it's easy to set up any number of lambdas/cloud functions/workers to respond to webhooks.

Furthermore, in the "Workflow builder" and "In-browser IDE", all the author is highlighting is the case where the service provider is hosting the handler code, as opposed to the customer. But a whole, major point of webhooks is that they allow clients to run code in reaction to their SaaS APIs' events, but in their own infrastructure. I mean certainly, of course, if the provider wants to take the cost and risk of running their clients' code, that's a great service to provide, but I wouldn't say that highlights the negatives of webhooks.