I don't think it has to do with language but rather with interface patterns. Qt Widget was made to do native desktop apps like Word; QML was made to do touch apps like on mobile. Embedded has shifted to adopt touch screen and copy interface patterns from mobile (where touch based interface were innovated first).
You don't want a Word-like app in your car dashboard, but a iOS-like app.
Except that on iOS you can do everything in Objective-C/Swift if you feel like it.
Same applies to Android, UWP and even Tizen with their respective native languages.
So it is a conscious decision not to provide C++ APIs besides the old QtWidget and make developers use QML and its compiler instead, as far as I understand it.
It's not as clear-cut as that. This is a case for automotive, and there isn't a single native UI widget set that Qt could use/mimic. It absolutely makes sense to use QML for custom UI development, it really shines there -- using Qt widgets for custom UI on touch screens would be madness.
I've used Qt myself for desktop, mobile, and embedded development. For mobile and embedded I would not use widgets, and probably not even for desktop. I understand why the widgets still has staunch fanbase, but they do not belong everywhere.
You don't want a Word-like app in your car dashboard, but a iOS-like app.