Good question - I see this often. I think it's not that it's bad, just that it never managed to gain traction because it was:
a) never marketed properly (I never knew about pysfml until I came across this thread, for instance, though I knew there was a C# wrapper and a bunch of others)
b) as a result of a), not as popular among Python programmers compared to the de facto pygame
c) as a result of b), using pysfml may mean less support when you get stuck, and since it isn't well-known you don't know how stable it is, which means more potential costs and risks using it. For instance, googling pysfml right now, I can find its home page and some docs, and a couple threads about people praising/using it, but I cannot find any forum dedicated to it, except a subforum on the sfml forums which appears quite inactive (compare this to the .NET wrapper forums) - this is going to be a show stopper for a lot of people
d) there also appear to be at least two (competing?) versions of pysfml, one called "pysfml" and the other called "pysfml 2 cython", which is going to further confuse prospective users - it's also confusing that version 2 does not appear official, yet seems to succeed to the original pysfml, while being incomplete - again, discouraging users from spending time playing with it
At this point in the chain of reasoning, most people browsing around for a library to write their game with will have gone with pygame or similar, simply because they don't have the time nor the inclination to learn a new game library that nobody else seems to know about and potentially not be able to get help in a timely fashion if they have problems. Yes, it is a bit of a chicken and egg problem, which most competing software has to face.
Unfortunately, some libraries never really transcend the language they were written in (and, thus, for) despite the existence of official wrappers. It's easy to end up believing a Python game programmer will immediately know what sfml is, but the reality is communities of programmers from different languages are often almost completely disjoint and can be quite ignorant as to what is happening outside the bubble of their language, tools and frameworks. Piercing that bubble to get people to use your wrapper can be hard.
