This technique is similar to one that I have used with good success in a number of DNN 3 and 4 modules. Note however, that the author is not describing a means of dynamically loading DNN modules (which is what DNN itself does) but rather a module that dynamically loads user controls (.ascx) to change its presentation of data, user interface, etc. For example on one site (http://www.ctamaine.org) I have several instances of the same module - one showing a datagrid of community access centers, another access center e-mail address, and another of access center websites. The main module (loaded by DNN) includes methods for searching and loading data from the database and for testing user permissions. Then, depending on a ViewKey value (stored as a TabModuleSetting), the parent or wrapper module (or switchboard as the article calls it) uses LoadControl to load one or more user controls to present the data in different ways. The primary advantages (as opposed to DNN's use of the module "key" to switch between a module's various controls) are that 1) one needs to write only one module control with its often complex code and then write several (often very simple - sometimes only requiring different .ascx controls but the same code behind) view controls and 2) DNN's default behavior of switching to an admin skin showing only the current module for any module controls having other than the blank "key" is avoided.
If you are interested in doing something similar, here's an important point: each dynamically loaded user control should inherit from either PortalModuleBase or better yet, from your own custom class that inherits from PortalModuleBase. After the parent module loads its child user control, it should then pass its own ModuleConfiguration object to the child control. This makes it possible for the child to access the same vital information as its parent - ModuleId, ModuleSettings, etc.
Finally, if you're interested in studying this technique further, I have developed the start of a framework for defining and loading what I call ModuleViews which subclasses PortalModuleBase, ModuleSettingsBase and ModuleController; creates DNN database tables that somewhat parallel ModuleDefinitions, ModuleControls, etc. but for ModuleViewDefinitions, ModuleViews, etc.; and during installation of a module with child views parses a Views manifest xml file similar to the DNN module manifest file. As I'm still having problems with the installation phase due to a lack of reliable "hooks" in the DNN module installer to allow a module developer to run custom code during the module installation process and due to a lack of time to properly document the framework, I consider it more of a work in progress of interest to the experienced developer. If you would like to take a look at the source code to get better insight into this technique, you're welcome to register at my site (http://www.wesnetdesigns.com) and then download the WESNet DNN Modules Base Install (for DNN 4 only). The base install also implements PortalModuleSetttings which are truly global across the portal for any instance of a particular module (unlike ModuleSettings and TabModuleSettings).