Details on why Blender should use bWidgets rather than an existing widget/GUI toolkit.

Why would Blender use and even develop bWidgets instead of an existing Widget/ GUI toolkit? There are multiple things to consider here.

TL;DR: Switching to an existing toolkit is a massive effort with rather high risks and unclear benefits. A custom solution made specifically for our needs is a much safer bet.

Making the Switch...

... would be a massive effort

Oh yes, depending on the toolkit, the effort might be massive. Even for the most basic features (like widget drawing, handling and layout-management), it would be a huge project. With most toolkits we probably wouldn't be able to do a progressive (step by step) transition, it's all or nothing. So only at the very end, we'd see if our efforts were worth it.

On the other hand, creating our own toolkit - bWidgets - is a huge project too. But in this case, we can develop it progressively and specifically for Blender. There's much less risk of failure.

... may not be worth it

We all know it: Blender is special. It follows a very uncommon set of UI Paradigms, and we don't want to give up on them.
External toolkits are based on different paradigms and are designed specifically for these. We had to make quite some customizations to any toolkit's default behavior.

Imagine, we go through the major hassle of making Blender use an existing widget toolkit and we gain nothing from it. It may happen that our customizations to the toolkit may end up costing more time to maintain than a custom solution would. Or say development of the toolkit is stopped.

... might not work in the end

It's barely possible to estimate all requirements we'd have for a toolkit. And thus it may happen that after months of work, we notice a major issue with the it. Even for the requirements we can figure out now, somebody who really knows the toolkit would have to judge if it can meet them.
Add to this the factor that we have very limited plan on where to take the Blender UI in the next years. We don't know yet what future requirements may come up.

With big projects such as switching to an existing GUI toolkit, there's also always that risk of developers who drive the effort loosing their interest. With a more gradual transition, we can merge the changes in more gradually too.

... makes us rely on third parity projects

We would give away great control over how issues are handled and how priorities are set. Now, we'd rely on release schedules of these projects for some of our UI changes. What if the toolkit decides to switch to a newer version of the C/C++ standard - one that we can't support yet?
Again, keeping this freedom is not for free either.

Issues with other Toolkits

There are many existing Widget Toolkits. Each have their own pros and cons, there is no magic bullet for Blender. Let's look at some of their cons to see if they are an option at all.

Qt

• Focuses on applications that are entirely built with Qt. For Blender we'd only use some basic widget related components of it. It's not certain if that's even possible without making Blender entirely Qt based. [TODO check this!]
• Would increase Blenders binary size quite a bit. [TODO test how much.]
• Adds additional dependencies
• Uses language extensions (meta-object compiler - MOC) as part of their API. We'd have to use those and compile using the MOC.
• Has a very long compilation time (only matters if we compile it ourselves).

GTK+

• GTK+ is focused on Linux and more specifically the GNOME project. Other platforms are much less of a priority and thus have many issues.
• Adds quite some additional dependencies.
• Duplicates lots of functionality we already have in our C code.

Dear ImGui

• Designed for debug tools
  From its README:
  Dear ImGui is designed to enable fast iteration and empower programmers to create content creation tools and visualization/ debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal, and thus lacks certain features normally found in more high-level libraries.
• Limited theming support.
• Limited layout features.
• Small feature set.
• Maintained by a very small team (currently mainly one person).
  Nothing against that, just important to note that we probably wouldn't have many people to help us in case of issues.

WxWidgets

• Uses native platform widgets with their native look. Such look is not something we want in Blender by default though.
• Because of this focus on platform native looks, theming is not that well supported.
• Focused on Windows, Linux support may be neglected.
• Depends much more on platform, so platform specific bugs are more common.

Points for a Custom Widget Toolkit

Of course bWidgets will have its own issues, just like any other solution would. And it still has a long way to go before Blender can make good use of it. Nevertheless, having full control over it, we can set our own priorities. No third parity projects involved that decide on our behalf which bugs need urgent fixing and which don't. We can stick to the dependencies Blender already has and don't need to customize the behavior to fit our paradigms. Instead we just make the toolkit be based on our paradigms. We can make themes and the Python layout scripts compatible so there's no need to recreate them. And we can make a careful transition, step by step.

bWidgets intends to strictly isolate the widget code so that it can be replaced much easier in future. And since its design is more conventional, a switch to an existing toolkit would be much easier by then too - even if just for testing purposes.
That said, if bWidgets works out the way it's planned, it should be a superior option to any existing toolkit, simply because it's made specifically for Blender. Making a big portion of our UI code ready for the next decade.