TL-DR: it is the highest (=most urgent) priority that shell-spawned processes can be assigned by the scheduler.
Wordy explanation
ulimit gives control over the resources available to the shell: it reports and/or sets such limits.
The -r flag reports the highest priority to be assigned for scheduling to a process spawned by the shell. Since priorities run from 0 (most urgent) to 99 (least urgent), this means that processes spawned by the shell (those belonging to the real-time application classes) can achieve the highest scheduling priorities.
Processes are classified either on the basis of their use of resources (I/O-bound or CPU-bound, depending upon whether they mostly use I/O or CPU resources) or, more relevantly here, on the basis of their degree of urgency (a non-technical expression). There are interactive processes like the shell: since we humans are slow and dumb, the pc wastes a lot of time waiting for us to even lift a finger. However, once a key has been pressed, these processes need to be given high priority unless we feel the system to have become unresponsive; the average delays must be of order 50msec or so, and with small variance.
There are also batch processes, which do not need user interaction, run mostly in the background, hence are given low priority by the scheduler. A typical example are scientific computations.
Lastly, there are real time processes which impose the strictest constraints on the scheduler. In this category fall video and audio recordings and playback, data collection from physical sensors, robot controllers. These processes must be given the highest priority to allow them to carry out their tasks.
The fact that such priority, as reported by ulimit, is 0 does not mean that this is necessarily 0: 0 is the hard limit, you can set a soft limit at smaller values, and you can increase the priority up to the value of the hard limit, which however in this case also coincides with the maximum available in the system.
