I don't like it and would miss the OK/cancel buttons for many dialogs. As others have pointed out, it becomes more forgivable if you can undo the changes, but therein lies the problem.
You don't necessarily want your undo system to capture changes to, say, application preferences. Otherwise that gets goofy when you hit ctrl-z or cmd-z to try to undo a change you made inside the application's world or canvas or whatever only to undo changes to the application's system preferences when you were trying to undo a brush stroke or text change, e.g.
And it's typically in those application preferences/settings/options where you tend to find these OK/cancel dialogs. So I really think they're fine as they are, at least for cases where it makes no sense to store an undo entry for the changes you make in that dialog.
A practical improvement if you ask me is to make it so changing whatever is inside the dialog gives you an interactive preview so that you don't have to hit "OK" before you can even see the changes. But that doesn't require getting rid of the OK and especially the "Cancel" button which lets you discard the changes if you don't want to keep them.
I also think there's a bit of a craze to make everything non-modal these days, and maybe some dialogs are definitely better if they're non-modal. That said, I don't find it makes sense to allow an application to have 7 non-modal file dialogs open at once. Often the non-modality comes at the cost of making it more difficult to rapidly open and close that dialog (ex: being able to close it with escape key and restore the focus back to whatever had focus before), so I still like modal dialogs here and there in cases where it doesn't really benefit the user much to be able to open a boatload of the same type of dialog.
I worked in a team where they thought everything modal was bad and foul and something to be made non-modal, so after a great deal of work, we ended up with an application where you could, indeed, open like 7 "open file" dialogs at once. And I only found the workflow more awkward and cumbersome than ever before where I could no longer just hit ctrl+o, navigate to a file, and hit enter to select it and open it or escape to close back out and restore the application control focus to whatever it was on before. With the non-modal file dialog, it also didn't close when you selected the file(s) to open. It would stay open, so you had to close it with a separate step. That encouraged this very cluttery UI with way more non-modal windows and dialogs open at once than you were actually interested in unless you manually closed them to manually clean up the UI all the time. With the previous modal design, the UI would automatically stay clean since the dialogs would close themselves after you selected the file(s) to open, e.g.
Imagine if Starcraft had a non-modal design. Then instead of this:
You might have a screen with 800 icons on it in docked panels, representing all the possible options you could perform in the entire game with 99% of them being grayed out and disabled and not making any sense in any particular context. The super rapid workflow of Starcraft is possible because it favors this kind of context-sensitive modal sort of design where you have to select a unit, click an icon (ex: "build"), then you get something like a modal pane/matrix showing what things you can build with that unit with buttons to cancel and go back and so forth. It's a "one step at a time" modal mindset and it's due to the simplifying nature of that modal design that there are Korean players who can perform like 300+ actions per minute.
If you ask me, applications should be more modal and contextually driven like this focusing on one thing at a time, not many things at once, if we want to allow users to work really, really quickly.
