I'll give it a shot; apologies in advance if it gets long, apologies if some of the wording is not "exactly correct", apologies for leaving out things like SMP, multiple CPUs, scaling, etc because I'm trying to keep it simple.
Every command you run, every program that runs on a system has to share the resources, CPU is the one that we are interested in here.
Why CPU? Because the program does not run until it's "in the CPU" (CPU being told to load instructions from address abc and execute them).
How do you share the CPU amongst more than one program? You run a little of one, switch, run a little of the next one, switch, and so on. The switch and "the next one" are where things get tricky. Before the switch, you need to save where you are right now (process state). "The next one" is also tricky, because you need to choose. If you choose poorly, the user is going to wipe the system and install a different OS.
The "how to choose" is the main job of the scheduler.
The main factor in choosing is the priority; priority is simply a means of saying how important something is. I'm sure we've all worked at jobs where "everything is the most important thing that needs to be done"; doesn't really work in real life does it?
Code that handles interrupts (think ethernet packet coming in on a device, needs to get pulled into the stack and given to a program) is basically the most important thing in a system and needs to be handled "right now".
A shell script that is recursing directories and validating checksums (think of some of the stuff in periodic that runs at 3:00 am) is at the other end of the importance scale.
User programs are everything in between typically (X responding to a mouse or key is pretty important, actually displaying the key on a window is less important).
RT stands for "Real Time"; a special case where you have strict timing limits on handling data. Think Video or Audio where you have needs of handling data in say 10 ms (interrupt handling is on the order of microseconds or less). So "rtprio" is an indication of something that has strict timing needs, but is not as important as an interrupt.
Scheduling priority: simply an indication of where in the list the scheduler has placed the program "right now". The right now is important. Why? Every program/command run starts out at a default priority, roughly middle of the pack, to give everything a chance to run. As the program runs, the scheduler may change that priority. Why? Perhaps the program is waiting on a resource that something else is using and that something else is more important. The one waiting will get a temporary bump so it doesn't get locked out forever (deadlock is the typical phrase describing this). So the important piece is the scheduling priority starts at a value, may go up, may go down temporarily, but returns to this base value.
nice: Remember growing up and mom always yells at you to "let your sister/brother/cousin/friend" have a turn? That's the concept of "nice". Remember when you start a program/command that it starts at some default priority? Well the "nice" command is used to tell the system that you think this process is not as important (typically a user can only "nice down" or make his process less important). That effectively tells the scheduler instead of using the default priority as the base value, use "default priority minus the nice value".
Simplistically, I hope that all makes sense to you and answers at least some of your question.
The tricky parts come in the scheduler because the choice of "the next one to run" gets complicated in a hurry. How many CPUs, how expensive to switch a process from one CPU to another, how many things are running, is something an interactive process that a user is waiting on (interactive is typically not as fast a people think. You hit a key, can you tell if it got displayed in 2ms instead of 1ms?)
I think I'll stop here before I get in trouble.
