Well, The UI in general does not contain any information on what the setting of the various options mean. There are help files / man pages for that. It would be nice if you could right-click on every control to pop up a window that displays the relevant paragraph in the manual for that parameter. But at the moment that is only science fiction.
I don't think it would be so counter-intuitive if the UI already showed a setting of the required syntax in the EGTB path text entry, even if that was with path names to non-existent directories. I.e. preconfigure the settings in a useful way. The problem here seems to be that the -defaultPathEGTB option is pre-configured, and has priority for display over the -egtFormats option, so that it eclipses it. The policy of always trying to mimic old behavior as closely as possible in case of extensions obviously fails here. The priority should really be that the value of -defaultPathEGTB is only displayed if the -egtFormats string is empty, not the other way around.
The problem is further compounded by that we want to preserve the user's settings from previous versions when he upgrades to a new version. That really means we cannot pre-configure anything except options that did not exist before. All current WinBoard users are likely to have an empty -egtFormats string in their settings file, and WinBoard currently contains no mechanism to force a value on options that are currently empty strings. It would anger people that have set a value for -egtFormats if this value was overwritten by a dummy example for the syntax each time they upgrade. I guess a future version could make -defaultPathEGTB a volatile option (not saved in the settings anymore) so that it would quickly revert to its default value of the empty string, but when for whatever reason it would be non-empty after startup, append it, prefixed with the word "nalimov:" to the -egtFormats option, and then clear it.
I don't see the merits of what you propose. Why shouldn't an engine want to use multiple EGTs? This is not a certainty at all, and the UI should not enforce such a limitation on the engine. Most users want engines that play by (adjusted) DTM, if DTZ50 tells them the current value of the ply counter allows it. So the engine would have to probe both Syzygy for the DTZ50 and Nalimov for DTM. Or the engine might want to probe Scorpio bitbases in search and Nalimov when reaching the end-game. Or the user could have installed only 3-5men of the flavor the engine prefers, (Say DTM50), but 6-men of another flavor, (e.g. Syzygy) so that the engine would like to switch when reaching the 5-men stage. It is upto the engine to make such decisions, the UI should not cripple it by withholding information. If the engine wants to delegate this decision to the user, it can make an engine-defined option for this, as with every parameter it wants the user to set.
[Edit]I now pushed a patch that will still go into 4.9.0 for always clearing the -defaultPathEGTB option after appending it as nalimov to the -egtFormats, so that the 'EGT path' text entry in the Common Engine Settings now will always display the -egtFormats setting.