Events in Drupal allow various system components to interact and communicate with one another while remaining independent, or decoupled. The event system is built on the Symfony event dispatcher component, and is an implementation of the Mediator design pattern.
As an application grows in complexity, and additional components are added, it becomes necessary for those components to communicate with one another. Rather than having objects refer to one another explicitly, which can quickly turn into a maintenance nightmare, communication is instead facilitated by a mediator object. This reduces the dependencies between communicating objects, thereby lowering the coupling, and creating a code base that's easier to maintain.
When writing custom code you can dispatch events in order to notify other components in the system about actions taken by your code. For example, the Recurly module works with the Recurly web service to facilitate subscription billing. The Recurly web service handles the recurring logic, and charging of subscribers. Whenever a charge is made Recurly sends a ping notification to the Drupal Recurly module. The module receives the incoming notice, opens its contents, and uses that to make changes within Drupal. It would be impossible for the Recurly module to hard-code every possible action that someone might want to take when a user cancels their subscription. So instead, it takes the incoming notice, wraps it in an Event object, and then dispatches a new "recurly ping received" event, to which any number of different modules can subscribe and do things like cancel the Drupal user's account, send an email, display a message, or anything else you as a PHP developer could conceive of.
Event subscribers respond to specific events being triggered and perform custom logic. Which could be anything from updating related settings when a configuration change occurs in another module, to redirecting a request after inspecting the request parameters.
