What it's good for

First of all, I kind of agree with you that it is not easy to find an application, or even a set of applications, that do not work _at_all_ with the current combination of best-effort + fixed priority real-time scheduling.
In fact, this is right the scheme that is implemented in Linux as for now and --fortunately for all of us! :-D-- Linux already works very well in many contextes, and succesfully runs thousands of applications!

On the contrary, since no deadline scheduling is in place, not only in Linux, but nor it is in the vast majority of all existent (even real-time) operating systems, it is hard to find an example of an app which is happily scheduled by deadlines at this moment! :-P

This said, the point here is if there are some kind of workload that would be better represented by a runtime/deadline/period model than just by a priority value.
Since you're looking for examples (and, to me, you're right in doing that!) we can consider multimedia applications, that are intrinsically periodic (or sporadic) --e.g., 25 frames per second-- and that intrinsically have deadlines --e.g., presentation times for frames.
Thus, especially if, as many are saying, we have quite a lot of these applications, would life be easier if we let them specify their requirements a little bit more naturally than asking them (or the sysadmin) to tune/tweak their priority?
I think that this is not going to be necessarily true, but if we want to try it out, we need a deadline scheduler! :-D

Then, from a more ``academic'' point of view, which is better from fixed priority and deadline based scheduler is a long struggle, which, as years are passing, is turning into a legendary tale, an epic saga... :-O
Here, in real-time scheduling theory, we have, among the others, two major algorithms: Rate Monotonic, which is fixed priority (prio = 1/task_period), and EDF, which is dynamic.
Again, my personal opinions are:
- FP/RM is very simple to understand and to implement
- FP/RM yields slightly smaller implementation overhead
- FP/RM is very predictable and deterministic, a lot useful in hard
real-time scenarios
- EDF is more flexible and still predictable
- EDF allows better exploitation of system resources (CPU, both on UP and
SMP)
- EDF has more graceful performance degradation in case of system
overload (kind of fairness, bounded tardiness, etc.)
- EDF, for the reasons above, is often considered to be better suited for
soft real-time workloads, especially on mixed rt non-rt systems.

And again, which is the best one? Well, I'm not going to answer! :-D
By the way, I hope I added some bits to the discussion, did I?

Regards,
Dario

1) A buggy task which gets stuck in an infinite loop, rather than locking out all lower-priority
tasks and effectively locking out the system as it would with RT sceduling, would just use up
its allocated time. This could be a huge debugging aid and reliability improvement in such a
system.

2) A high priority task can leave some CPU time to lower-priority tasks. For example,
suppose you have a high-priority computational thread which occasionally spends several
CPU-seconds at a time, and a low-priority communication thread. It would be good to limit
the computation thread to consuming no more than 90% of the CPU, so communication can
proceed. Of course, it would be even nicer if it got all 100% when the communication thread
didn't want any.

Audio, video, 3D accelerated applications (video games) - all these are noticeable if they starve briefly.

Although assigning real time priority to all the applications will work, you can cause a denial of service on your own system and root access is required to set real time priorities without prior configuration.

That's too much risk and work for me, the lowly user.