Could be. That was what my 2nd-to-last paragraph was about. I just think that opening up that output channel to let developers run free with event data will produce some very interesting and creative uses that perhaps IFTTT hadn't considered and let people create one-off solutions for services that IFTTT doesn't yet support (such as my need last night, which I solved (sadly) with yet another Twitter poller).
Your post should have then been "IFTTT should cater to developers" not "IFTTT needs webhooks." IFTTT's entire thesis is that non-developers should be able to 'program' computers. Just because you want webhooks and they would be cool doesn't mean IFTTT should work on features that go against the entire premise of their product -- and if you think they should, this is the primary argument you should be making, not if they should be adding feature X or Y. Surely if IFTTT's target market shifted from the general public to developers, there would be many things developers would want, and webhooks is only one of them.
Absolutely agree on this one with you. We are working on similar product http://elastic.io and it's clear that in this business (IFTTT, Zapier, elastic.io, FoxWeave.com, etc) you need to work on two customers - business customers who pay and developers who are platform multipliers. That's the reason Zapier and IFTTT are trying to open up. Important is however business users (who pay) do not need 'developers' view on things, they don't need the 'flexibility' and complexity that developers needed, so essentially it's two different products. Think AppStore/App - Xcode.
