W-a-a-a-y back in the mists of time, during the MacOS days, it was recognized that Macintosh power users wanted even fewer context switches than the Macintosh was already delivering. There were hooks that allowed savvy software companies to create extensions to the MacOS file dialog, which allowed just exactly what you call "stupid and inconsistent". For users who wanted to work as much as possible through the GUI via the keyboard, these file dialog extensions allowed a lot of customization to workflows. These customizations were apparently popular with the graphics artist set; when I spoke with some of these folks out of curiosity (since I agree with you that cramming these features is wildly inconsistent with the Mac design principles, but an awful lot of them were buying these packages from me at the time), it turns out that it was a very practical way to wrangle lots of projects and lots of files in each project going on at the same time.
It was a variation of the highly customized key bindings you see lots of vi/emacs/terminal users create, often by those who deal with workflows that have a repetitive aspect, but not repetitive enough to automate. It just so happened these key bindings were all in the file dialog. Since these were primarily graphics artists who I found were the most vocal about these customizations, it totally made sense to me then why they wouldn't be living in emacs and customizing that instead. Mostly actions like "jump to this folder", "copy this filename", "search in this folder", "recursively search from this folder", "serialize these filenames", etc. Very edge case activities compared to mainstream GUI users, but it turned out immensely useful to this subset of users; literally saved them up to an hour per day, which added up really fast.
I sometimes wonder if they weren't onto an aspect of GUI development that seems to have languished in recent years. There used to be a sense in GUI design development of an incremental, iterative progressive disclosure of GUI features to accommodate neophyte to expert users alike, and slow down no one in that entire spectrum of operational expertise and/or desire to manage complexity. The Windows and Mac GUIs these days seem to be far more monolithic in how they treat the user spectrum (Windows a little less so, in that there is more room customization, but I don't really see a lot of users adopting the available customization software), and seem less layered and nuanced. I'm sure this reflects really well upon vendor support costs, but some days I wonder how we can bring to the mainstream GUI-oriented users the deep customization benefits that we programmers take for granted on our text-oriented tool suites.
At the same time, the KDE and Gnome environments allow this kind of customization (and then some), and they haven't really taken the mainstream GUI world by storm either, so I concede that this might easily just be a worse is better situation, and the kind of advanced GUIs we programmers think are cool are simply not practical for everyday users.