There was an article by Raymond Chen where he argued that giving app developers an API option to say "run me under high/low priority" rarely works because every developer views their program as the main character on the stage and couldn't care less about other programs' performance, and they are incentivized to enable the "high priority" option if given a chance because it makes their program run better (at the expense of other programs). So unless there's a strict audit on some kind of app store or some API rules which enforce developers don't abuse the priority API, sometimes it's better to let the OS decide all the scheduling dynamically as the programs run (say, a foreground UI window automatically is given a high priority by the OS), so that the scheduling was fair.
The way it’s conceptualized on Apple platforms is primarily user-initiated vs. program initiated, with the former getting priority. It’s positioned as being about tasks within a program competing for resources rather than programs competing with each other.
So for example, if in an email client the user has initiated the export of a mailbox, that is given utmost priority while things like indexing and periodic fetches get put on the back burner.
This works because even a selfish developer wants their program to run well, which setting all tasks as high priority actively and often visibly impedes, and so they push less essential work to the background.
It just happens that in this case, smart threading on the per-process level makes life for the system scheduler easier.