Your clean list alone shows SFML isn't clean. If SFML has "intuitive usage" then there would be no posts on this forum as everyone would just instinctively know how to use SFML without a document or tutorials. Resident Biscuit's misuse of the three functions again show it isn't intuitive otherwise he would not have posted this thread.
You got a very wrong definition of 'intuitive' in your mind. Intuitive doesn't mean everything works for everyone with no learning curve. It only means the if you know part A it will be very easy to get to part B.
Take the touch mechanisms as example. I think mostly everyone would agree that touch movments are intuitive. Now if you give a device capabale of those inputs to a person not familiar with them at all, you'll notice that only some will automatically understand that pitching with two fingers will zoom, or swiping will get you to another screen/state. So intuitive in a technical sense is not just to know blindly how to do things, but more like an easy way to understand and discover new things, when a few certain rules are set.
And everything can be misuse in some way, it doesn't matter if it's intuitive or not, e.g. I have a computer mouse, throw it against the wall and it breaks, is that now the fault of the vendor or creator of that mouse?
Only big difference I've noticed is SFML abstracts the process more than the other two libraries.
As Nexus said abstraction is a good thing, or why do you think nobody is programming in ASM anymore? A computer is a product full of abstraction, physical interactions -> electronic stuff (transistor) -> logic gates -> processor -> bit code -> assembler -> higher programming langues like C++.
Also the name API means Application Programming Interface and interface is what connects diffrent abstraction levels.
So from my point of view this statement says that SFML is better than SDL or Allegro sind it uses a better abstraction.
As for consistency, that is a good thing, but wouldn't take it at face value. That could just mean they don't care to change the API or only tweak the function body to optimize the library while adding new functions here and there. I know a programmer that does just that, I've told him he needs to make more creative names in his library he made for his team a few years back, but he has been consistent there because he doesn't want to make more creative and memorable names for the functions. While others, like Allegro 5, got the API renamed to reflect that A5 was a new library and not like the A3 or A4 libraries before it.
Have you looked at the difference between SFML 1.6 and SFML 2.0?
I'd say SFML 2 is a completly new library with sooo much changes. Take the function change Laurent made from CamelCase to camelCase which still confuses people and so even hate the change, but you can't say SFML is limiting itself.
Also do you think SDL doesn't care for consistancy at all? Wrong! Because if they wouldn't be consistence the library wouldn't be available on nearly all linux distros by default. With that you can be certain that you're program will just run under linux and don't have to worry about compability etc...
It implies that you choose your tools according to your feelings, instead of the usual technical details (design of the API, documentation/tutorials, features, ...)
So which would DirectX fall under? That is the ugliest API I can even think of.
I don't really get the connection between the quote and your answer, but if you wanted to say you don't use DirectX because it has an ugly API then this falls again into the same category as Nexus as pointed out.
I don't choose DirectX because I can decide between OpenGL and DirectX and only OpenGL is crossplatform so the choice is really easy. If I wanted to make a fullsized AAA game just for Windows I
might use DirectX regardless the ugly API, but because it
may give me more power to the OS supported functions.
As I said, it is just my opinion. Any ugliness I think there is I just remedy by wrapping them in a function of my own. I don't stress over it, lot easier just to wrap them and keep going than to worry about the developers possibly fixing them. Since the developers and other users don't think the API is ugly then I will just continue to wrap it and use it that way. No need to rock the boat over interpretations of clean and ugly API as the API works fine even though it isn't to my tastes. After 16 years I have just become accustom to doing wrappers anyways 
.
Do you really go down the path to: "This API is ugly but I won't tell you why."
We're all eager to know what your opinion is and what you think should be made better. So the worst thing that can happen is that your suggestions just get rejected, so you got nothing to lose at all.
If you for some strange reason really don't want to tell use what in your opinion is ugly, then you could maybe enlight us on how you'd create a wrapper for SFML. You know there's nothing wrong in having it's on engine/code laid out to use a certain interface for a renderer and then write a 'wrapper' that connects the wanted interface with the selected renderer, but that doesn't mean the other API is ugly, it just means that you match your ideas with the one of the library.
Since you like to point out your 16 years of experienc I'm curious to see some of your work to maybe learn a few new tricks. And are those 16 years from the first time you've read something about programming or from the time you got hired as programmer or contributed to a bigger open source project?
So please tell us your opinion!
