I prefer TGUI, as it is a much smaller library. It's easier to integrate than SFGUI, in my opinion. TGUI can be drawn to anything derived from RenderTarget whereas SFGUI (as far as I can tell) can only be drawn to a render texture or render window, so I can render TGUI to custom render targets if needed. Not that I necessarily do, but the ability is there. It seems odd, but I can think of some ways this could be useful.
TGUI isn't too difficult to theme. It uses a CSS-like syntax for that, which makes skinning it much less cumbersome than calling "setColor" for every element. SFGUI theming appears to be closer to true CSS than TGUI, but that includes signifying hierarchical theming in the theme file. I dislike CSS for how complicated it can seem, so I prefer TGUI's way of theming. TGUI's theme parser won't tell you where a syntax error or, it only tells you what character it was expecting. SFGUI will give you enough information to debug the error. SFGUI will print to std::cerr, wherever that may be directed, to present the error. TGUI will throw an exception, which will crash you if not caught. That's neither good nor bad, it just is. I wish TGUI gave more information when it encountered a parsing error, so I didn't have to hunt for the extra character hidden somewhere.
Both could probably do with a nice overhaul in terms of theming and layouts. Specifying layouts in external files would be ideal, but that's quite a feature to request, and exactly how that would be specified/handled would be up for much debate (though if anyone does want to discuss such a feature, I have plenty of ideas). Until then, we will develop our own, since we're using TGUI for our engine and editor, and it has to run on basically any display 720p and larger.
The last time I used SFGUI, it crashed under SFML 2.4.1, but TGUI works. I have not tried with SFML 2.4.2 yet as it only just came out and I'll have to upgrade my projects.
Like Turbine said, TGUI makes event handling really easy. It returns false if no event was consumed so you can know whether or not to pass the event down.
That being said, it would be nice if TGUI allowed us to force the size of some elements, both x and y. Vertical tabs would be nice, too. Spacers between list/dropdowns, and using ellipsis for truncated text that doesn't fit inside an element (or having that as an option).
SFGUI is a couple years older, so it just has the benefit of having been refined more. I wish both had a simpler way of laying things out, but I can't particularly think of a way to syntax that nicely. Positioning has to be defined somewhere, and right now that's on us. I imagine TGUI will get more feature-rich as time goes on, as will SFGUI.
I'm not sure about speed comparisons. They both seem to perform just fine. I've yet to experience a frame drop because of either.
SFGUI has more elements, but, again, I imagine that's likely because it is older. I may try contributing to TGUI once I become more familiar with its internals, though it appears no one has contributed more than a couple chunks who wasn't Texus.
We've been able to make TGUI interactivity scriptable in our engine, though I think the same could be done with SFGUI without much difficulty. You can specify a string in TGUI to identify every element, and that is used in the scripts to specify which element to edit, since it doesn't store a pointer in the script.
SFGUI has the advantage of having some of the SFML devs working on it. TGUI doesn't have that luxury. That being said, I'll be starting my Ph.D in the fall, focused on graphics, so perhaps I'll be able to provide input to TGUI that'll be of use.
All of my impressions could be totally invalid, and its obviously highly subjective. Take it with a grain of salt, and nothing personally.
/endrant
