A desvantagem mais imediata de executar um processo em tempo real é que o processo pode facilmente deixar passar qualquer outro processo no sistema. O resultado do seu ponto de vista será que o computador não responde completamente ao teclado, ao mouse e provavelmente à rede, enquanto o processo em tempo real estiver usando a CPU. Isso pode acontecer se algo der errado e o processo entrar em um loop infinito, ou mesmo temporariamente, se o processo iniciar um cálculo de longa duração sem esperar pela entrada periodicamente. (Por exemplo, não execute o SETI @ home com prioridade em tempo real.)
É menos provável que um processo único de thread único em uma CPU com vários núcleos cause esse problema, pois há outros núcleos que o processo de prioridade mais baixa pode usar. Mas se esse processo criar qualquer processo filho, eles herdarão a mesma prioridade em tempo real, para que as coisas saiam do controle se você não for cuidadoso.
A página do manual sched_setscheduler(2) tem um bom conselho:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
Isso deve ser um shell no console - não sob um Xterm, a menos que você queira dar toda a prioridade X em tempo real também.