License issues aside the typical use case is that you want to integrate the UI with an existing 3D renderer (e.g. you have a 3D engine, and want an UI overlay for tooling and debugging). 'Bring your own renderer' UI frameworks like Nuklear or Dear ImGui are perfect for this use case. With 'traditional' UI frameworks like Qt, WPF, GTK... this is a massive PITA and even if it's possible would add an incredible amount of bloat.

...and then there's also the convenience of writing immediate mode UI code. Personally, I would never want to go back to event-/callback-/signal-driven UIs.

In addition to what others have said, they are different types of GUI systems. As an immediate mode UI, the logic behind what gets drawn to the screen in Nuklear runs every frame, and it draws/updates the entire screen every frame. A retained mode UI like QT draws elements once when they need to be updated, and they get left there until an event occurs that requires something change. So immediate mode UIs like Nuklear and Dear ImGUI, tend to be more appropriate for rendering the UI elements of games and other programs that already draw/update the screen each frame. Retained mode tends to be more useful for traditional "desktop" like applications where interacting with the standard toolkit widgets serves the primary purpose of the program. Of course there are many ways of blurring the lines and using either for both, so this isn't a hard and fast rule, just a rule of thumb.

QT is a huge dependency that you have to bundle with your app. This is tiny in comparison. Also probably easier to prototype with.

rapid development/prototyping