Just because the application asks for something doesn't mean it gets it. Currently, the kernel acts as if applications all want all of the processor time. But some applications actually only want some of the processor time. If an application can only make use of the first 1 us of every 1 ms, and asks to run only then, the kernel may be able to give it 100% of the time it wants without any system impact; if, on the other hand, it can't tell the kernel, it has to busy-wait through a lot more processor time in order to get any change of being running then, and load the system much more heavily.
The right design is to assume that programs want everything, and let them say what they don't want. Then you don't give them anything they don't want. Then the usual fairness and best effort goals essentially work again: if you have a batch process and a realtime process of the same priority, it is equally bad to miss the realtime process's window once as to not run the batch process at all for 1 ms; that is, the scheduler should try equally hard to avoid either happening, and fail about equally often under random load. Of course, writing a scheduler that does this optimally is hard, but the theory shows that it is possible to give userspace controls such that a program can benefit by decreasing its demands on the system.