ISR - to flag or not to flag?
Designing by rules of thumb you found on the internet someplace is a bad idea.  The right way is to understand the issues, them make intelligent tradeoffs.

There is nothing wrong with a system that takes a interrupt, clears the hardware condition, then sets a flag for foreground code to do the remainder of the processing when it gets around to it.  The danger in that is that the foreground code might not get around to it in a while, and if the same condition occurs again before that, information might get lost.  Or, if something needs to be handled with low latency or jitter, then you probably want to handle it in the interrupt routine.

Again, understand the tradeoffs.  Interrupt code runs immediately after the condition occurred, at the expense of everything else the processor might have to do at the time.  Is that worth it?  That depends.  How much delay can you tolerate in handling the condition?  How important is it that the foreground code not be delayed?  It should be obvious that there is no universal single answer to this.  It is highly dependent on the particular application.

For example, if part of the processors's job is to respond to a serial command stream that is sent to it at 115.2 kbaud, then bytes can be received as fast as every 87 &micro;s.  The interrupt routine could simply set a flag to let the foreground routine know it should read a byte from the UART, but that would require the foreground code to check the flag at least every 87 &micro;s.  In many cases, that would be difficult.  A good tradeoff for many cases (again, this might not fit any one particular case) would be for the interrupt routine to grab the byte from the UART, clear the hardware condition, and stuff the byte into a software FIFO.  The foreground code then empties the FIFO as it can, probably in bursts between performing other tasks that can take longer than the 87 &micro;s byte time.

On the other hand, the interrupt routine for a user button might only perform debouncing and set a flag when the button is in a new state.  The system only needs to respond to the button in human time, which can be many milliseconds.  If the foreground code checks all events at least every few milliseconds, then there is no need for the interrupt routine to do any more of the processessing than described.

In general, the interrupt routine should do whatever immediately latency or jitter-sensitive processing needs to be performed due to the event, then set state so that processing that can respond slower can be performed later from foreground code.  Again though, don't just run off using that as a rule of thumb.  Understand why.  Then you won't need any rules of thumb.