I interpret your question to be the following - if that's wrong, forget this post :-(
Why are all settings put into one single dialog, with a left side navigation, instead of providing a menu structure which allows to open (amodal) windows for different kinds of settings (e.g., viewing preferences vs. file locations, "diverse functional groups" in @tohster 's answer)?
I can think of the following usage scenarios:
Initial Configuration (user does not know any settings): Your users wants to quickly get an overview about all available settings (and default values). You can present a sequence of steps in the sequence of hierarchy nodes which is in some form logical. The user can see his progress while working down the list. Re-opening the settings menu to find the next step requires the user to keep track of his progress.
Exploration (user does not know where to find a specific setting): This is easier when clicking through a hierarchy with details displayed on the side immediately. Opening and closing windows is more costly.
Spot Changes: (user knows where to find the setting): Both the hierarchy and the submenu navigation support this equally well. There might even be a small advantage because there's less clutter when using your menu+window idea.
Now if I think about the relative importance of these three scenarios, I'd optimize for the first and second, since if the user doesn't find the settings he likes quickly in the beginning, my app may be uninstalled (I am quick with this :-). Even if there is a small benefit for the expert, I'd trade that for safety with novices.
I would guess that your idea of having multiple settings windows open can have some benefits when the settings interact somehow. But in this case, they belong into the same functional group, i.e., on the same page and not in different windows.
Hoping I answered the right question,
nobi