It's a trade off.

With ImGui you can definitely have a GUI that is:

  1. Very complex
  2. Able to use custom, complex widgets
  3. High performance
  4. Written very quickly with a very simple API

Those are significant pros.

There are a few serious downsides as well:

  1. It is not remotely conforming to the platform's standard UI (a bit less a problem for a DAW since they all have custom GUIs and widgets anyway)
  2. The font rendering is done by the GPU using cached textures, so it's more limited in terms of what you can achieve there (not so much a problem for DAWs because you don't have much text to display)
  3. Power usage can be high unless you use tricks to adjust the frame rate dynamically
  4. It's in C++, which can be a con for some people (although it's written in old-school C-like style)

If you can live with those, it's a great solution.

People do crazy stuff with Dear ImGui: https://github.com/ocornut/imgui/issues/5886

(And keep in mind that many of those are week-end / hobby projects, by people who prefer to focus on other things than the GUI of their projects.)

Even Lisp programmers decide to pragmatically use an OOP model when doing GUIs.

The idea of using FP for everything is about as sensible as the paradigm of using OOP for everything.

You say that like CL programmers are inherently functional, which has never been true. They have always embraced OOP when needed

Less, I would say; because using OOP for everything is straightforward, just obtuse, verbose and possibly slow.

You don't have to solve paper-worthy academic puzzles to use OOP everywhere.

Using OOP everywhere has been done and probably continues to in some shops. There was a time in the 1990's when nobody was fired for using OOP everywhere.

In Common Lisp, absolutely every value you can create has a class: the class-of function is meaningful for any value. You can replace all the defun forms in a Common Lisp program with defgeneric and defmethod.

Title should be changed to Rust GUI Development Struggles.