Donald: You cannot argue that "the effects of a long/bad ISR tend to show up "once a month in a released product"". This may well be true for a 'bad' ISR, but why should it be so for a long one?
Because if the long ISR is on the edge of e.g. killing a UART interrupt, for the effect to show requires that the UART int arrives less than 1us after the EI0 int. The trickiest case I have seen, when asked to fix something was a case where another interrupt had to arrive very shortly after the long int AND the long int had to take a particular path for the effect to show up.

Michael: I think that Erik's reaction is related to having had his fingers burned in the past and so he has the tendancy to venture down the side of the field along a narrow furrow. The path is guided, low risk and comfortable.....and if you don't look over the side always looks pretty much the same in front of you and in back of you.
No, my fingers have not been burned by this (on a '51, I learned this with the PDP-8), just ever so often, when asked to fix someone elses stuff I see just this. Also see below.

so to restate:
If you spend days/weeks to verify by code analysis (you need the assembly, C will not tell) that a long ISR will not hurt, go ahead. If you are not willing to do so, avoid them.

My way of handling a long ISR when required:
Find an unused interrupt (UI) and set it at a lower priority than all others (IP, not the "simultaneous priority"). In the ISR where you have to do things 'now' do the very minimum and set the bit that trigger the UI. Then let the UI do the rest of the processing. That way, the only process being 'hurt' is the main and that can be made safe by much simpler means than an ISR.

Erik