The author hand-edits a C++ file, autogenerated by CMake. In that sense it still needs a C++ compiler as part of a build step.
A binding relying only on Rust and QML might replace the C++ boilerplate with a Rust equivalent.
At no point is there a need to edit a generated C++ file. Any other build tool with C++ support could be used instead of CMake. What it should do is call rust_qt_binding_generator when the binding description changes.
The table in this blog shows what files are generated: https://www.vandenoever.info/blog/2017/09/04/rust_qt_binding...
Well then maybe your example should reflect that, where a change is made in the C++ file replacing 'Simple' with 'Time'
It can be seen inside the template project here:
https://phabricator.kde.org/source/rust-qt-binding-generator...
From that perspective, there isn't any. Dyed-in-the-wool "QT app-devs", if there is such a category (KDE devs?) already have access to Rust libraries, in the same way they have access to most stuff in weird compiled languages: you wrap the library in a C ABI and call that. It's a well-understood process in QT land.
I think this project is more an effort to give Rust projects access to a native graphics toolkit (that happens to be QT) for adding a GUI to a previously CLI application. I could see, for example, the Parity Ethereum client (written in Rust) getting a native system-tray/notification-area widget written in QT.