I don't agree. SFML sounds at first like a really good idea, and at first usage seems pretty cool. But there are invisible walls and they're not hard to run into. The API reflects the developer's way of thinking and I find it somewhat odd (though, to be fair, I'm sure plenty of people would consider the API I've built for my own private library to be somewhat odd, too), and I noticed in my most recent experiments with the 2.x beta that you end up having to drop out of the friendly confines of the SFML libraries into the underlying implementations alarmingly often to do anything interesting.

There are also what I consider reliability issues. SFML 1.6 and 1.6 have reproducible startup issues on any semi-modern ATI/AMD graphics chipset I was able to test it on (2008 to 2010 vintage). The recommended solution from the developer was to upgrade to the API-incompatible 2.x alpha--which still isn't even released as a 2.0 today. It's open-source, and totally his choice whether or not to fix bugs like that (at the time I wasn't capable of doing it myself); I'm not saying "oh, he's not at my beck and call, he sucks," but I'd be very wary of going back there again and it did play a factor in me choosing not to use SFML for my current project.