SFML is not a threading API, it only provides what it needs internally.
So, if it's really intended to be used solely by the library itself, it shouldn't be exposed to the user - all in all, you don't put the internals of your classes in the public section, do you?
Otherwise, if it's really meant to be available to the user, why you're refusing to implement this feature, even though it's literally several lines of code and some users apparently need it, as you see?
Yeah, SFML is not a threading library. And I don't even want it to be. It's a multimedia library, and therefore, if it provides threading support, it'd be nice if it let the user set the priority of the thread, because there are circumstances when one want to run threads with different than default priority in this kind of applications.
About boost.thread... Quite frankly, I think that many developers don't want to depend on boost. It's simply a big mess. Sure, there are other libraries, but still - if SFML let me to change that priority, I wouldn't have to depend upon other stuff (yay, smaller size of my proggy!).