Maybe it's just me, but I think you guys would want SFML to perform as fast as possible, regardless of how skilled the programmer using the library is.
The library is already designed to operate as fast as it can without sacrificing any of its interface design. The fact that it currently limits itself to the legacy OpenGL API comes from its history and considering that ancient hardware might not be able to provide anything else is another factor to consider. What people tend to forget is that SFML currently only has a
single rendering implementation, that it uses for
all platforms. It was probably previously infeasible for Laurent to support multiple rendering implementations by himself which is why he restricted SFML to merely supporting what was necessary to get consistent results from SFML no matter what hardware was in use.
Like I said, this might and probably will change in the future because a) SFML now has more development resources at its disposal and b) more and more people (even beginners) are putting more value into using the modern OpenGL API and coupled with the fact that the hardware that doesn't support it is becoming less and less common, SFML will have to start making changes that target future hardware that might not even provide the legacy OpenGL API any more.
In regard to a feature such as sprite batching, is the concern not wanting to clutter the API, or is it more that it's not considered low level enough to implement?
Both. For me, you can separate API levels into 3 categories. Low, middle and high. A low level API would be just 1 step above the operating system, common examples include OpenGL, OS socket APIs and OpenAL (although this is debatable). Mid level APIs are normally focused on taking the low level APIs and providing some benefit over them. In the case of SFML and SDL, it is the portability that such libraries guarantee. They abstract away the differences between the low level APIs that operating systems bring along with them, easing the development of cross-platform applications. This does not mean that they are limited to providing a thin wrapper on top of said low level APIs. They can also provide helpful functionality that encompasses the wide majority of use cases developers would have when usually resorting to the lower level APIs.
SFML tries to satisfy the perceived needs of its target audience which in turn means that almost all of their legitimate use cases will be covered by the library in one way or the other. This is where things get a bit more complicated. Until recently, its target audience consisted of people who were merely interested in simple 2D graphics, simple audio and rudimentary network access. It had been this way for years, which is why the API ended up being like it is now. I can't speak for Laurent, but I can imagine he simply didn't know that there were many people like those who posted in that reddit discussion that found SFML lacking the features that they would need to consider using SFML seriously. I have been a proponent for expanding SFML's perceived target audience for years, but I haven't gotten much backing, since people who shrug SFML off often don't even mention why they do it. That reddit discussion contains more information from such people than you will find on this forum in the last 3 years.
I think SFML succeeds at doing what it was originally designed to do, provide simple access to multimedia and networking for beginners to have a bit of fun with. Going forward, I hope Laurent recognizes that SFML has much more potential if it were to open up to a bigger audience, which would mean it has to provide features that the new audience also seeks without sacrificing any of the values or ideas that make it the library it is today. It is going to be tricky, but I'm pretty sure it isn't impossible.
As for the question at hand, taking into consideration what I just said, sprite batching simply wasn't a feature that would benefit SFML's target audience enough for it to become a core feature of SFML. It could always be built on top of SFML, which is why it never really had a high priority, and that would also keep the core API clean for those who didn't need it. One might argue that having API documentation pages that are hundreds of pages long because of all the auxiliary features isn't a bad thing, but considering that we urge beginners to browse the documentation to learn more about how to use SFML, it isn't that friendly either. Just like the C++ standard library, we like to keep the API concise. It has just enough for you to build arbitrarily complex things on top of it, no more and no less. This way, we can also keep an overview of the feature set that SFML is meant to support. A mid level API really isn't destined to become too huge, and is often smaller than the lower level API which it is built upon. If we expanded SFML to encompass higher level features as well, it would just explode. People might start asking "but you included feature X so why not include feature Y too?" which would lead to a chain reaction and ultimately API bloat.
Since there isn't anything else higher than "high level" it can and often does include everything all the way to very domain specific features which really shouldn't have a place in a general purpose multimedia library. This can be seen in many other libraries out there. People might adore them for exactly this reason, but they tend to forget that if they look around at the others who also use said libraries, they all tend to come from the same domain for exactly the same reason as well. I don't know about you, but I can hardly call such libraries general purpose any more.
