may be unfair---tasks may starve
e.g. job submitted to the IBM 7094 at MIT in 1967 and not discovered til 1973 (cos it was a very low priority task which was starving in the bowels of the scheduling system).
Useful to have some kind of priority mechanism, simply because the processes on a system are typically of very different natures. Some are interactive. Some operate in the background. Some users are logged in at the console, some are on remote terminals. Some are part of the operating system, some are user tasks...
Usually makes use of RR scheduling between same-priority tasks.
Internal priorities based on CPU usage, I/O (blocking) time, resource usage, process size, etc. That is, the scheduler measures some properties of the running processes, and bases its priority on them.
External priorities are where some jobs are considered inherently more important than others. They are set explicitly by the user, or by the creator process. (For example: "render this complex 3D scene, but don't damage my interactive performance.") Textbooks give amusing examples about students getting the lowest priority, just below janitors.
Reducing priority of high tasks to give lower tasks a go (or, converesly, increasing the priority of processes which have not had a go in a while.)