Most administration systems are normally presented as a set of relatively independent modules. It is believed that those modules should share a common look and feel and that's about it. Linuxconf was originally started this way. Soon enough, it appears that in order to do a "better" job, the various modules had to exchange informations. Or they had to share many different services. Or they were simply sharing common code.
The idea of a core component came from there. Basically, Linuxconf is a large core offering a wealth of services to modules. The core is made of
Creating an "all modules" solution introduces much more complication than it solves. A fully modular solution yields simply to modules which often do half of the job because they lack to ability to trigger the proper action from another (potentially not installed) module. So the idea of a well known core enhances the ability of module to perform a good job.
As a side note, one may acknowledge that the Linux kernel is using the same strategy to deal with modules. The level of support needed by module is also quite important because of the advanced features Linuxconf provides (and a module is expect to deliver).
So it is simpler to evolve modules from a stable core than inventing a protocol "du jour" so two logically tied modules may talk and request informations or actions from each other.
Currently, the core of Linuxconf operate happily on a low end 386 so there is little pressure to modularize it to extremes.