The selector is not modular, is builtin but I am 100% sure that it doesn't add loading time or memory usage.
I don't use new resources when starting the selector, the background is the same, icons are already used in the resto of the interface, also the code relevant to the selector is called only when you start it. There are no resources taken for the selector at startup.
I preferred to implement it builtin because it allows to quickly bring up the selector and eventually to return as quickly to the main interface if you change your mind...
The size of the executable is basically the same and if the loading times have increased it's not because of the selector (they may have increased because gmenu2x now starts the services such as samba, inet etc.. but it does it in parallel so it's not a big slowdown).
Why I think that a separated frontend and commandline support is a general better idea?
Because it allows another developer to implement a better interface than the one builtin the emu (sometimes emus are not opensource and you cannot modify the interface) also allowing other users to choose which interface is best for them.
Because it brings consistency (in my opinion the biggest advantage). It's much more user-friendly having a single interface for all the emulators.
And there are other advantages that I can't recall now
