I honestly don’t see a single downside, as long as it’s modularised, maintainable and with clean APIs. And e.g. with a configuration module: The place where I’ve experienced this was a place where bigger parts of the configuration module were classes to build specific custom tree configurations. And if one module would just save what should happen at the change of each entry (and not save that with that entry), it would need to duplicate the whole structure and map it to the entries, which is ugly. It just makes sense to put those strongly related configurational things into one configuration module which provides an easy API (one method for changing and one for retrieving a config element after constructing it and adding other modules).
I honestly don’t see a single downside, as long as it’s modularised, maintainable and with clean APIs. And e.g. with a configuration module: The place where I’ve experienced this was a place where bigger parts of the configuration module were classes to build specific custom tree configurations. And if one module would just save what should happen at the change of each entry (and not save that with that entry), it would need to duplicate the whole structure and map it to the entries, which is ugly. It just makes sense to put those strongly related configurational things into one configuration module which provides an easy API (one method for changing and one for retrieving a config element after constructing it and adding other modules).