One example of my "creative" use of interrupts.

With good planning, a lot can be performed at interrupt time, without consuming too much time or affecting the interrupt response times.

A receive interrupt need not limit itself to just taking a character and put in a receive buffer. It can also process SOM/EOM bytes and compute a running checksum. Then, the main program don't need to spend time checking if there are received bytes, but can check if there are received packets.

Large number of times can be handled by a sorted priority queue, in which case the application need not loop through a large number of timers to see if anything needs to do. The timer interrupt can decrement the head of the prio queue, and set a flag if timeout. That gives a constant time in the ISR - for any number of timers - while the main loop can wait with deciding "what" needs to be done until it sees the flag that "anything" needs to be done.

With a bit of work, very complex applications can be written using a super-loop, without making the application impossible to maintain. The hard part - but it is always hard - is to prove a worst-case response time for any combination if timeouts and input stimuli.