As you say, events are a great tool to reduce coupling between classes; so while it can involve writing additional code in some languages without built-in support for events, it reduces the complexity of the big picture.
Events are arguably one of the most important tools in OO (According to Alan Kay - Objects communicate by sending and receiving messages). If you use a language which has built-in support for events, or treats functions as first-class citizens, then using them is a no-brainer.
Even in languages without built-in support, the amount of boilerplate for something like the Observer pattern is fairly minimal. You might be able to find a decent generic eventing library somewhere which you can use in all of your applications to minimise boilerplate. (A generic event aggregator or event mediator is useful in almost any kind of application).
Is it worthwhile in a small application? I would say definitely yes.
- Keeping classes decoupled from each other keeps your class dependency graph clean.
- Classes without any concrete dependencies can be tested in isolation without consideration for other classes in the tests.
- Classes without any concrete dependencies require fewer unit tests for complete coverage.
If you're thinking "Oh but it's really only a very small application, it doesn't really matter that much", consider:
- Small applications sometimes end up being combined with larger applications later on.
- Small applications are likely to include at least some logic or components which may later need to be reused in other applications.
- Requirements for small applications can change, prompting the need to refactor, which is easier when existing code is decoupled.
- Additional features can be added later, prompting the need to extend existing code, which is also much easier when the existing code is already decoupled.
- Loosely coupled code generally does not take much longer to write than tightly coupled code; but tightly coupled code takes a lot longer to refactor and test than loosely coupled code.
Overall, the size of an application should not be a deciding factor in whether to keep classes loosely coupled; SOLID principles aren't just for big applications, they applicable to software and codebases at any scale.
In fact, the time saved in unit testing your loosely-coupled classes in isolation should counter-balance any additional time spent decoupling those classes.