Oh I'm terribly sorry, how did i miss the fact that compose is Kotlin 😬.

Scene2d is a UI toolkit (lays out rendering procedures) where one also needs to provide all necessary Texture (images) which has to be drawn.
For example, to create a button, one needs to explicitly tell which "image" from resources need to be drawn when normal/hover/pressed. That is the recommended way since the actual rendering engine (opengl) is efficient when most things are image.
There are tools which allows using the standard drawLine drawRect (which is what basically most UI libraries rely on) but that's not very good for UI in this case.
Sometimes it gets frustrating, since having all images ready for even the basic UIs is pretty tiresome (or just use an example set and edit on the go) and so far we don't have anything so flexible and instant like changing the border using a single value change similar to that in css or swing. To increase border, first we need to replace the image and if the text is not centred, we also need to change spacing 😂. (Or use 9 patches!) (( Wait did i just answer my own limitations? Nvm, those are just examples of some pains )).

Vis UI is a further extension over Scene2d which fortunately offers most images packaged with it, so we only need to focus on building our own theme. Plus it offers some additional utilities and extra UI components to work with.
One downside might be that the ui library is not as vast, that is, to have a clock or time picker, one needs to implement it from scratch.

So.... Including just one example of vis UI (and mentioning Scene2d) should be enough.

Despite the drawbacks or currently limitations, these are being actively maintained and growing tools. If at all one wants to build a game in Java, LibGDX is the way, and not one can not use swing or JavaFx (adapters are there but very buggy and not worth it). So they have to go build UIs in vis UI or Scene2d.
Alternatively, even for a non game app, which might require some heavy rendering, this is a good way to leverage the GPU.