Was it a thing anywhere except recently? Going through some different native Windows apps, I see a host of different file choosers (many of which were once "the one" for their version of Windows), and they all belong to the same process as their respective applications. Definitely not to a privileged service. (Unless Windows is doing something exceptionally fancy here?).
A lot of this stuff was "decided" back when we had serious memory constraints, and less technology to manage them. Switching processes was costly. Running the file chooser in the same application was an excellent compromise. A solution. (I remember an article about this problem in the context of early MacOS, along with drag & drop and the like. Will share if I find it).
In addition, having the file chooser in-process makes sense if you're trying to appease app developers, who think they want the ability to change everything. In particular, they'd really like to add a custom preview widget and some other gizmos to the file chooser. Photoshop puts all sorts of buttons in its Export dialog, for instance. And because Photoshop does it, a bunch of other applications think they should, too. And they still want to, even if they're using Gtk.
Saying "this is dumb, we need this dialog to be a simpler interface for [reasons] and if your app has a weird file dialog you'll have to deal with it" is a very decisive action, and it is not without friction. So I think the reason this took so long is partly an accident of history (the bad solution stuck because it was too late by the time we could afford the good solution), and partly just luck: things reached an inflection point where app developers actually get something (sandboxing and clever app containers) in exchange for the inconvenience.
But the time where the overhead mattered in any way is over since well over a decade.
Even when e.g. GTK3/QT5 was released the overhead of a out-of-process file chooser was more then irrelevant.
> makes sense if you're trying to appease app developers,
I have yet to see a single application which uses that for any reassemble thing which couldn't also work with a native file chooser (e.g. custom preview images) or can be handled well outside of the file chooser (but then I'm on Linux since quite a while, but this is about Linux in the end).
I have been hearing complains about non-native file chooser pretty much since I started using Linux 12? years ago. In difference to very few Linux programs customizing anything but filters in a file chooser.
So I don't buy that it's inconvenient for developers to any relevant degree (wrt. Linux) the very few application which insist on it still can roll their own file picker by using on of the "guaranteed to pop up" custom file picker libraries.
One the other hand having file picking as a system service would have lead to more consistent appearance, more convenience (consistent system interactions) and more accessibility (e.g. alternative system file picker specialized for blind people).
So you will have a hard time convincing me that it wasn't dump to not switch to native file picker around a decade ago when GTK3/QT5 came out, sure there where reasons, but there had been much more reasons in favor of it then against. It's just not a decision anyone ever did actively I guess, because not making a decision is easier then people across distros/GUI frameworks agreeing to making a decision.
A lot of this stuff was "decided" back when we had serious memory constraints, and less technology to manage them. Switching processes was costly. Running the file chooser in the same application was an excellent compromise. A solution. (I remember an article about this problem in the context of early MacOS, along with drag & drop and the like. Will share if I find it).
In addition, having the file chooser in-process makes sense if you're trying to appease app developers, who think they want the ability to change everything. In particular, they'd really like to add a custom preview widget and some other gizmos to the file chooser. Photoshop puts all sorts of buttons in its Export dialog, for instance. And because Photoshop does it, a bunch of other applications think they should, too. And they still want to, even if they're using Gtk.
Saying "this is dumb, we need this dialog to be a simpler interface for [reasons] and if your app has a weird file dialog you'll have to deal with it" is a very decisive action, and it is not without friction. So I think the reason this took so long is partly an accident of history (the bad solution stuck because it was too late by the time we could afford the good solution), and partly just luck: things reached an inflection point where app developers actually get something (sandboxing and clever app containers) in exchange for the inconvenience.