At SFML, we believe that the developer should have an understanding of the work that is being done by the library when such "optimizations" are undertaken. If we have the feeling that we would have to impose too many artificial limitations on developers just so that some other developers can save writing a bit of code themselves, we often just let them write said facility on top of SFML.
Sprite batching is no different. Many have requested this in the past, and I might be wrong, but I have the feeling not many understand how it really has to work under the hood. Like Ixrec said, you can batch quads together into vertex arrays, and yes, you can do so even with multiple sets of texture data. I explicitly say texture data and not just texture, because logically, the texture object is what the GPU uses to source texture data as you already know. However, nothing prevents you from batching multiple texture data sets into a single texture as well. This is commonly known as texture atlasing. SFML already does this with its text rendering, hence it shouldn't be too big of a problem for you to implement this for sprites as well.
I know what you are going to say now, why doesn't SFML do this for you since you think many might need this and this is what a multimedia library is for. I already mentioned the answer above. Different people will need different kinds of sprite batching. Writing an efficient sprite batcher is very application specific and having to account for every possible thing that developers might use it for would probably end up making it slower than simply drawing the sprites yourself.
It really isn't that hard to write your own, assuming you understand how one works that is. Try it out and you can always come back here if you have questions.
