Here's a few suggestions. No advertising, just down to earth embedded talk. As a newly hatched engineer I remember going to great lengths to avoid using interrupts in my embedded designs, covertly fearful of my ability to debug the code. With growing experience and confidence that changed to an undisciplined use of interrupts in every conceivable area, figuring that they'd speed system response and show everyone just how clever I was. A horrible bit of reality intervened, in the form of a high-speed tape system that had only microseconds to respond to each incoming data byte.
Interrupts are indeed wonderful.
Interrupts do, however, impose execution penalties that you simply must account for. They also complicate debugging, since these asynchronous events can confuse your tools. Though it is important to recognize their limitations, interrupt-Luddism is an awful mistake. Interrupts play naturally into the use of a Real Time Operating System, which lets you buy, rather than foolishly rewrite, a significant chunk of the real-time sequencing part of your code. They can introduce an element of chaotic behavior into your design.