The way I understood it, libui is a widget toolkit (e.g. GTK, wxWidgets, Qt, etc) -- while SDL is low-level library to handle drawing, input (i.e. you'd need to implement your own widgets using the low-level primitives that are available to you).
SDL isn't quite "lower-level"; it used to stand for Simple Directmedia Layer. It's a layer over some common drawing operations and the instantiation of a window.
So you get a box you can draw in, and that's it. Then you're allowed to poke pixels until you get what you want. It's not that you're poking a lower level (which would be akin to directly blitting to the screen buffer like an old-timey OS), it's that you're poking a different level (creating a new context and performing operations on it, via GDI+ or OpenGL or whatever). You trade one set of primitives for another.
It's absolutely lower-level. How do you think those widgets get drawn in the end? Via primitive operations like GDI+/OpenGL or just bit blits.
GUI Widgets are a higher level of abstraction on top of pixels. SDL gives you pixels or an OpenGL context which gives you a slightly abstracted way of rendering pixels.
Then if libui supports libsdl as it does to gtk-3.0 it would be nice, as gtk-3.0 is still quite heavy for many embedded systems.
libui is based on C, and it is not really suited to compete with the c++/java full GUIs on Desktops, so supporting libsdl will certainly expand its usage.
The way I understood it, libui is a widget toolkit (e.g. GTK, wxWidgets, Qt, etc) -- while SDL is low-level library to handle drawing, input (i.e. you'd need to implement your own widgets using the low-level primitives that are available to you).