This is answered in my book, so I'll just quote the relevant paragraphs.

Many operating system scheduling algorithms adjust the execution priority of processes in proportion to the amount of CPU time that they have consumed recently. In very busy Oracle environments, this has the unfortunate effect of degrading the execution priority of key background processes, such as LGWR, DBWn, LCKn, and LMDn. This causes an increase in scheduling latencies for those processes, and can in the extreme make the entire instance bottleneck on the services of the affected background processes.

Where priority fixing is not available, you may be able to obtain equivalent relief from the priority degradation mechanism by artificially raising the execution priority of the key background processes, or even running them in the real-time priority class. You may feel reluctant to do this, on the basis that Oracle has often recommended that all Oracle processes should run at the same priority. The rationale for this recommendation is to prevent the possibility of a low priority process holding a critical resource but being unable to free it because of CPU starvation, while other high priority processes try repeatedly to obtain that resource. However, this rationale scarcely applies to raising the priority of the background processes. These processes will soon sleep if the resources they require are not available, and beyond that will only consume CPU time in proportion to the amount of work being done by the rest of the instance. So, there is no risk of CPU starvation for other Oracle processes.

In one of your answers you have mentioned that the LGWR can be assigned real time priority, but the SA's in my company (they work on Sun Solaris v 2.6) say that real time priority should never be given to database processes -- now I am sure that they are (blindly) telling me something which they have read from some manual and that there is some intricate reason behind your suggestion. Can you please enlighten me on this when you find the time.