挺尬的，半斤八两，尬的意义不一样……
如果你要开发体验的话，那么原则上是 C#，毕竟 Qt 你想用舒服基础姿势水平不低……C#的应用效果其实吃亏，但强在你能用更短的时间折腾出更多不同的方案试错。当然，前提是能实现。
.NET 在框架的意义上吹亏的就是定制起来没 Qt 那么容易折腾（或者说 Windows 以外基本就没稳定实现能用），Avalonia 这种比较新的，具体坑有多少没试过不好说。
Qt 虽然开发效率是个槽点，但是还有 Python 绑定能用（好歹没那么啰嗦），所以也算不上决定性的缺陷（用不用得惯 py 就另说了）。
如果你说做商业项目，要考虑让人接手，那么还是 Qt 忍忍吧。个人项目就随便了。
用不用 QML 看口味。我是不想用，主要是不喜欢各种 ML 那套（有这功夫还不如折腾 SGML+DSSSL 去了）。
Flutter 响应慢和资源占用糟烂是预料之中的，毕竟底层的开发者自己都缺根筋：
https://github.com/dart-lang/language/issues/490 。
这类方案的开发者看上去的共同点是没有一个严肃的桌面客户端应用开发背景，整个技术栈的根本设计上就不用指望能解决此类问题，只能“优化”变通。
JS/Electron 之类的软肋也就是这个，而 Dart/Flutter 么，怎么说也不用指望有更好的资源来（各种意义上的）优化了。
大多数玩具也有类似的问题。Rust 实现的算是少数的例外，问题是 Rust 的这类项目都没多少存在感也活不大长，怕是所有第三方方案中最不靠谱的那类，支持就更加看脸了。
@
duke807 wx 基本就是个跨平台 MFC ，除了用纯 C++而不需要 Qt 这种 moc 以及性能稍微（在 C++的意义上）更好以外，没什么技术上的优势。工具和开发者社区更不用指望了。
我见过有长期维护的项目从 wx 切换到 Qt 的，比如 TortoiseHg 早期用的 wxPy 后来就切成 pyQt 了。
虽然开发应用未必需要很在意，wx 这类“原生”方案有个致命的架构扩展性弱点：不是所谓的 direct UI 。（依赖 Win32 的 MFC 和 WinForms 也有类似问题，但大部分正常的都没有。）
参考
https://v2ex.com/t/831456#r_11329552 。
@
neoblackcap 自己写一个当然是终极方案，不过就只是自己的项目用，太浪费了。
我就糊过能跨 NDS 和 Win32 的，上边 C++能做到都完全看不出是什么平台的（反正比 QtWidgets/QPA 那坨彻底得多），不过自己糊的开发体验嘛……mac 工作量不好估计，反正 Linux 的后端我是坑快十周年了。
imgui 这种 immediate mode 的半残基本也就算图形库了，都不算正经 GUI 库（撑死就是“画界面”外加输入套皮），GUI metaphor 基本都没在 API 体现，要在严肃项目里用还不如自己造轮子。
比起上面说过 wx 是缺乏可扩展性，imgui 这种就差不多没什么架构能被扩展。要从里面拆代码复用，那还不如自己照搬目的纯粹一点的图形库（ Cairo 、skia 之类）自己从头搭框架。
@
ZSeptember 说 Qt 资源占用多，对也不对。
比起大多数其它 C++方案 Qt 往往因为不必要的运行时元数据访问而确实经常更拉胯，但一般同等经验的开发者写起来不会比用 C#实现的更慢。也就 QtCreator 这样规模的应用比较容易暴露出瓶颈。
更重要的是这里可是把 Electron 都拉上场一起遛了，正经写想更慢实在不大容易。
@
wdhwg001 这只是相对其它成熟方案来说的，如果是相对自己糊界面库，这类问题就算不了什么问题，毕竟自己实现也得把这种东西折腾对，还是挺花资源的。
根本让 Flutter 无可救药的是上面说过的 Dart 的思路（同时也适用于 Electron ）。