For what its worth: I've never used JUCE for my UIs, and I don't think it will be necessary (for me), that's nothing against JUCE as a UI toolkit, but I think last time I checked there was a license fee for commercial use and I had already developed a minimal UI toolkit which used XLib to provide the UIs.
Reasons for using XLib:
1) As mentioned by other people, one of the problems with plugin UIs is that you don't know which toolkit the host will use, so by hooking into X at the most basic level I could get a UI that would work regardless of the host UI toolkit.
2) External UI is used because it allows the plugin to create its own UI with minimal interference from the host. I believe there is a feeling from some developers that external UI is not the way to go, but now that its in most hosts, there seems to me to be no harm in leaving it be.
3) One of the reasons (I believe) for some developers disliking external UI is that it needs some kind of IPC (if you really run the UI in another process, but as noted, I just run the UI in the same process, using external UI to provide the (one) function that was missing from the original LADSPA spec that would have made it possible to do UIs even in LADSPA e.g. the ability for the plugin to write back parameter changes to the host.
Also, external UI doesn't provide for the host UI to embed the plugin UI - from my point of view, my plugins don't need this (and would prefer not to be 'swallowed' into the host UI - so it works ok for me)
4) The problem with using XLib for UIs is that you need some knowledge of GUI toolkits at a very low level to be able to code a UI using it, but personally I think if that makes writing plugins a bit difficult then.. well it's just that writing high quality plugins (and software) is not easy despite what some people assume. The toolkit I have devised has also now been succesfully ported to work on windows GDI as well as XLib with minimal effort.
I'm not sure how well suil functions, I've not stressed it that much - I did experiment with wrapping my XLib UI as a 'fake' GTK plugin UI - which worked, and this is the kind of thing suil is doing at a low (XLib) level (I think, although obviously the developer would be a better person to say) - I think there may be a suil extension eventually that handles XLib UIs which would be useful (as this could work for JUCE too).
It will be interesting to see suil develop, my only doubts are that if it has to support a lot of toolkits then it may mean rapidly growing complexity - e.g. GTK to Qt is only 4 (host - plugin) combinations, but add e.g. XLib, SDL, JUCE, FLTK etc etc... But again this may be an incorrect assumption to make. Its an interesting approach to solving a complex problem.