No, I don't think so. For starters, the "real application" needs the ability to set RT scheduling as it sees fit, often on a per-thread basis. Having the "simple application" acquire a single RT priority on behalf of the "real application" before calling exec() is far too restrictive for many audio applications.
However, more importantly, even though the "simple utility" could get RT scheduling priorities (and permission to set them) from rtkit, the SCHED_RESET_ON_FORK flag would ensure that all this is lost across the exec() call. In this scenario the "real application" will never inherit the RT privileges.