I wonder if we should.

• We could use it in FileDialog to provide a list of acceptable file types, instead of the messy nameFilters property in https://doc.qt.io/qt-6/qml-qtquick-dialogs-filedialog.html#selectedNameFilter.extensions-prop I.e. rely on QMimeType::name() to provide the translated name for the combobox, rather than the user needing qsTr(); and rely on QMimeType::suffixes() rather than the user needing to remember to specify all possible suffixes for a type (.html, .htm, .xhtml, upper-case variants, ...)
• https://codereview.qt-project.org/c/qt/qtdeclarative/+/446349 is proposing a way to override the type of Image.source but I'd have the type there be a QMimeType rather than QByteArray
• I suspect the same idea will come up again with TextDocument.source https://doc-snapshots.qt.io/qt6-6.7/qml-qtquick-textdocument.html#source-prop
• TextDocument.saveAs() could make good use of it too (after the user has selected a particular mime type in FileDialog, so that we don't have to guess it based on the user's chosen file extension)

OTOH it's strange that it's not obvious how a user is supposed to construct a mime type even in C++. The only easy thing is to detect the mime type of an existing file. But if we want a value type in QML, we'd need construction syntax like Qt.mimeType("text/plain") or something, which is also silly. (Qt namespace being a kitchen sink for all possible JS type constructors)