For a lot of services like this I think the value prop is not monetary cost but more "this is no longer your responsibility". Since you already have a custom-built solution that is stable & operating efficiently, switching doesn't sound worth it to you. For a team that's looking to add webhook functionality for the first time, not needing to go through the implementation work themselves or need to deal with any maintenance longer-term could sound very appealing. I think it's akin to the rise of interest in user-management-as-a-service products, etc.

I'm not, to be clear, expressing an opinion that the business will be successful with that strategy or that I think it's a good trend. On the contrary, this overall trend of feature-x-as-a-service products depresses me a bit. We've gone from the old days when you had to write pretty much everything yourself (which sucked), to the days when there were a ton of feature-x-as-library choices (which was way better but led to complaints of web programming becoming a chore of just bolting libraries together), to the current trend of feature-x-as-service products.

It's a logical evolution in some ways - similar to libraries over roll-your-own, it reduces your own set of responsibilities. But it also reduces your ability to learn (e.g. from reading source) or grow beyond the provided service (much harder to swap out providers or roll-your-own when the current solution is a third party black box). It also feels depressing in that we've gone from a thriving ecosystem of software based on open source to a much more capitalism-first ecosystem of "this could be a library but then how would I make money off of it". (I realize open source funding & maintainer compensation/sanity is its own set of problems. I just wish we could work on those issues without turning everything into a product.)