I am not being flip I really don't get it. I just read a whole bunch of material on them and I can't figure out the use case. I am not talking talking so much about the API for which the advantages over things like signal() are clear enough. Rather it seems RT signals are meant to be user space generated but to what end? The only use seems to be a primitive IPC but everything points to them being a lousy form of IPC (e.g. awkward, limited information, not particularly efficient, etc).
So where and how are they used?
First of all, note that Ben's answer is correct. As far as I can tell, the whole purpose of realtime signals in POSIX is as a realtime delivery mechanism for AIO, message queue notifications, timer expirations, and application-defined signals (both internal and inter-process).
With that said, signals in general are a really bad way to do things:
signalfdextension) rather than signal handlers to process signals, they're no better than other IPC/notification mechanisms, and still potentially worse.
Asynchronous IO is much better accomplished by ignoring the ill-designed POSIX AIO API and just creating a thread to perform normal blocking IO and call
sem_post when the operation finishes. Or, if you can afford a little bit of performance cost, you can even forward the just-read data back to yourself over a pipe or socketpair, and have the main thread process asynchronously-read regular files with
poll just like you would sockets/pipes/ttys.