Event receivers have been part of SharePoint for years. They enable you to run code on the server in response to an event in a list/library. If you know how to create SharePoint farm solutions, they are easy to implement, but because they run on the server a poorly written event receiver can cause major issues, and as such are not allowed in O365.
Remote Event Receivers were the solution to the above. In this model, SharePoint calls a WFC endpoint for a specified event in a list/library. This solves the issue re running code on the server. So, create a WCF service, host it on some server, and configure sharepoint to call it for a specified event (this last step is done by deploying a SharePoint app AKA add-in)
Web hooks are the newest version of the above. Like remote event receivers, SharePoint is simply doing a call to another service for a specified event on a list/library. However, instead of a WCF service, the web hook is simply making an HTTP call (so, a POST to a URL). One option for creating a webhook is an Azure function: create a function based on an HTTP trigger, then register that function with SharePoint. Non SharePoint devs will like this, as they don't need to know as much about SharePoint to get this up and running. Again, it uses HTTP calls instead of WCF, which is another plus. Also, since other services use web hooks, it means that devs can build events for many services using one set of technologies, instead of having to learn a different system for each service. For example, wordpress supports web hooks, so a developer could support events in sharepoint and wordpress by creating azure functions, and wouldn't have to learn the esoterics of SharePoint add-ins.
Any future development should probably look at using web hooks instead of remote event receivers.
