Devices can use interrupts to signal all kinds of events. In fact, any change of state of the device or the device controller could be reported to the host CPU via an interrupt. It's all up to the designers of the device hardware and firmware.
(And, one would hope, they will at least ask the opinion of the poor schmuck who's going to have to write the driver. Far too many devices have been designed without such input, necessitating awkward, inefficient driver designs. In fact there have been cases where some of a device's capabilities were unable to be used to their fullest because the device's host interface - which includes, but is not limited to, the interrupt structure - was designed without awareness of what could and couldn't be done in the driver. But I digress.)
The material you quoted is correct as far as it goes, but it seems to me to be a very simplistic view.
I'm not sure how "output is ready" is different from "output is completed". (Ready to be picked up from the printer output tray?) Similarly, "input data available" and "input completed" sound to me to be pretty close to the same thing. They would probably, however, imply different required work on the part of the driver. To me, "input completed" would mean the incoming data is in the host memory and a local thread's I/O operation can be completed, while "input data available" would probably mean that the driver would still need to move it from the device's interface to an in-memory buffer.
But this is just semantics. As a driver writer you have to read the device host interface specs carefully to find out what's really meant by any given interrupt, and what you're supposed to do about it. Sometimes you even need to read the firmware code or study the logic diagram. (Is that an edge- or level-triggered flip-flop? The device engineers sometimes have the oddest notions! But I digress again...)
For a slightly more complex example, consider a communications interface with a FIFO. We generally want to avoid excessive interrupts to the host; for example, an interrupt per packet is likely too many. So our device might allow us to tell it about a series of buffers to be transmitted via a "FIFO" (first-in, first-out") interface, and the device will take care of moving them all out on the wire.
But we don't necessarily want an interrupt only when all of the buffers are done! It would be better if we were notified when, say, the buffer was down to just 20% or 10% full. When we get such an interrupt we'll put more buffers in the FIFO (stopping when it's full, of course). If we only got an interrupt when the FIFO was empty, there would be a slight delay before we could get the next buffer to it for transmission, thus reducing throughput. By giving us an interrupt when the FIFO is "about to be" empty we can eliminate that delay.
1What should input has completed even mean? Interrupts are signals from any device to the CPU, so they may say "I wrote your buffer at memory position x to disk/network/paper, you may use it for other puposes again". On the other hand, "output is ready" would be the CPU telling a device "Please take the data at position x and send it to disk/network/paper, and inform me as soon as I may reuse that memory"; this kind of signalling is not done by interrupt but by IO ports – Hagen von Eitzen – 2018-10-01T14:55:38.983