Drivers which request threaded irq handlers actually register 2 handlers in the call to request_threaded_irq(). The primary or "hard" handler runs at the usual IRQ contex, and it checks if the IRQ originated from the device. If so it masks out the IRQ at the device level and returns IRQ_WAKE_THREAD. Then the generic IRQ code can wake the thread that runs the threaded handler.
In the realtime context, it doesn't make sense to run the "hard" handler in a thread since it is already designed to be low latency and it would just turn around and ask for another thread to be scheduled anyway. Plus, since the hard handler masks the IRQ at the device level, the generic IRQ code can leave the irq line unmasked so that IRQs from other devices on the same line don't have to get inhibited also.
Not knowing this background, the paragraph from the article sounded like drivers requesting a threaded handler would get the old non-threaded behaviour. Hence my confusion.