Most of this is just forwarding code from KFileWidget, so we could just use that directly? I mean if our LO integration is going to be the only user of this class, then maybe we should start by adding this code there and only upstream it if we think more people are going to use it?

It's the problem that if class doesn't exist nobody will think to use it (or he will reimplement it).
After that it's not a problem for me to put this code only in LO :)
As you want :)

Hmm. I can see the usefulness, it's certainly much better than the way people have historically inserted custom widgets into QFileDialog (https://stackoverflow.com/questions/16987916/add-widgets-to-qfiledialog, URGH).

On the other hand, I'm wondering if this is going to be abused as a KFileDialog replacement, losing the "native" look-n-feel for the file dialog on Windows / macOS.
Well, that's certainly a pre-requisite for any custom widget to work, it should just be made extra clear to app developers that what they lose in return is the ability to get native dialogs on Windows and macOS (and Gnome, I suppose).

So, I'm OK with this, provided that this documentation is added:

The downside of using this class is that your application will not be able to get a native file dialog on non-Plasma environments (Windows, macOS, ...). For this reason you should really think twice before deciding to use it, as a custom widget might improve user experience within the Plasma workspace, but might make it worse for users who are used to the native file dialog. In 99% of the cases, you want to use QFileDialog instead.