Hmm, on reflection that is true - we're talking exec(), not fork().
However, there could be another issue. As I understand it, rtkit doesn't grant the requesting process permission to set an RT priority though sched_setscheduler(). Instead it grants a requested RT priority to the process. In other words it functions as a replacement for sched_setscheduler(). As I previously explained, many high-performance audio applications (for example, ardour, jack) are multithreaded and request different scheduling algorithms and priorities for different threads. The simple wrapper application would only be able to grant a single RT priority to what would become the audio application's main thread. That application (or any of its threads) would not be able to alter that priority (or maybe even drop RT scheduling).
Having a single global RT priority for all threads isn't flexible enough to ensure smooth operation of these applications (and in fact, in most cases only a few carefully chosen threads need to run at RT priority anyway).