The challenge with the plugin system Joomla has today is that it doesn't offer a standardised interface to react on CRUD events that are triggered in various parts of the execution flow. This doesn't make it impossible to create IFTTT like functionality. It does make it a lot harder as it requires to write adapter plugins that translate events into a common format.
Assume you want to build an email notification plugin that is triggered each time a article is added. This is very easy to build using the plugin system, if however you want to use that same plugin to send email notifications for a contact, or a category, or when something is added in a third party extension that would be a whole lot harder.. You would need to build a separate custom plugin for each use case, or implement specific code for each.
In a rule engine world, a rule can be applied anywhere regardless of the actor. To be able to do that you foremost need a standardised interface. This is an old problem in Joomla and the discussions around rule engines go back more then a decade now. It's not an easy problem to fix. It's something we tried to solve with the MVC in 1.5 but never really got enough standardisation in to be able to do so.
At Joomlatools we have tried to solve this problem in our LOGman extension: http://www.joomlatools.com/logman
by implementing the Activity stream API and creating adapter plugins to translates events to a common format and interface.
In its simplest form, an activity consists of an actor, a verb, an object, and optionally a target. It tells the story of a person performing an action on or with an object -- "Geraldine posted a photo to her album" or "John shared a video". In most cases these components will be explicit, but they may also be implied.
We created a re-usable component that implements the Activitystream standard and is capable of translating for a none standard interface to the activity stream interface. It's available on Github: https://github.com/joomlatools/joomlatools-framework-activities
LOGman just implements this component and provides a UI for it, 80% of the code is in the public repo.
Note: The activity API offers additional benefits...the JSON output can act as a read-only HTTP API, once you have standardisation in place it wouldn't be hard to go from there to a REST API, ... or even implementing webhooks all become very feasible.