I see this kind of sceduler being useful for two cases:
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.