There has been a lot of operating systems research in the last 20 years on extensible systems. Following the basic idea of microkernels (which sought to componentize most everything in the kernel) came extensive efforts to build more monolithic kernels that could be extended in various ways:
All of these extension facilities provided some form of safety, to limit the potential damage that an extension could impose on the rest of the system. Such safety properties, for example, might allow a multimedia application to extend the kernel to support better quality of service, while limiting the multimedia extension so that it does not accidentally corrupt the operating system. The need for such safety in kernel extensions is anecdotally confirmed by the phenomena of unstable Microsoft Windows systems, which are allegedly made unstable in part due to bad 3rd party device drivers, which run in kernel space.
In contrast, LSM imposes no restrictions on modules, which are (normally) written in C and have full, un-typed access to the kernel's address space. The only ``restriction'' is that hooks are mostly of the ``restrictive'' form, making it somewhat more difficult to erroneously grant access when it should have been denied. Rather, LSM depends primarily on programmer skill (modules need to be written with the diligence of kernel code) and root authority (only root may load a module).
It should be noted that LSM can get away with this weak module safety policy precisely because LSM modules are intended to enforce security policy. Unlike more generic kernel extensions such as QoS, the system is entirely at the mercy of the security policy. An administrator who permits an LSM module to be loaded has already made the decision to trust the module providers to be both well-intentioned and skilled at programming, as bugs in a security policy engine can have catastrophic consequences. Further sanity checks on LSM modules are superfluous.
It should also be noted that this is the traditional view of Linux modules: that loading modules into the kernel is privileged for a reason, and that care should be taken in the writing and selection of kernel modules. LSM module developers are cautioned to be especially diligent in creating modules. Not only do LSM modules run with the full authority of all kernel code, but they are especially trusted to enforce security policy correctly. Third party review of LSM modules' source code is recommended.
Finally, we note that LSM is much less intrusive to the Linux kernel than the other large modular interface: VFS (Virtual Filesystem). The need for support for multiple filesystems in Linux was recognized long ago, and thus a rich infrastructure was built. The VFS layer of the kernel abstracts the features of most filesystems, so that other parts of the kernel can access the filesystem without what knowing what kind of filesystem is in use. Anecdotally, the VFS layer is reported to be a nest of function pointers that was very difficult to debug. This difficulty may explain, in part, why the Linux community would like the LSM interface to be as minimally intrusive as possible.