I do agree with your comments, particularly with your rebellion against the usual mantra "Keep ISRs short and sweet". What is appropriate in an ISR is entirely down to the individual application.

Donald, every rule has its exceptions; however I have seen more malaise from bloated ISRs than anything else.
I have no doubt that you, Michael and a few others can carefully craft a system where, for a valid reason, an ISR is quite large.

While What is appropriate in an ISR is entirely down to the individual application is true it is still true that a system is less likely to fail if the ISR code is kept to a minimum. Above you may read "is less likely to fail" as "require less experience and skill of the programmer"

I will, in every case, try to keep an ISR to the minimum. Does that mean that if I can not code an ISR is 5 lines or less, I refuse - of course not. I do, however, for every function involving an interrupt, do a careful evaluation of what goes there and what goes in 'main'

Again, I can hardly count the cases where I have rescued projects that failed because of ISRs coded with no aforethought.

Look at the many posts here "I have 2 interrupts, when I enable either all is well, when I enable both, my system crashes".

Ignoring KISS as far as ISRs go require a skill everybody believe they have, but very few actually have

Erik