The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads.
However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT.
Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app.