Modularity vs Single class simplicity

Question

I have been part of the organization I work in for the past year and a half or so. The company basically writes Perl code and they have large amounts of legacy code which originally prevented the company from moving forward with any code changes. My first observation with the existing code was non existence of Modularity.

Over the time I worked here I, with the help of a few (who left the company), did a lot of hardwork Modularizing all the core sections of the application. I believe that we now have about 70% of the core systems modularized, coherent and layered. At this point in time I am accused of complicating the system design and everything I try to do is sort of looked at with suspicion.

To design these systems I applied all the best design approaches(patterns) and methodologies(SOLID) available or known to me. When I wrote it, it was all appreciated but now the developers want to revert back to what they believe as simpler methodologies(which basically involves having large single classes, doing 100's of things). I still do not believe that those approaches are actually going to lead to simpler design but no one is actually ready to listen.

To give an example, our code basically loads a bunch of files during its lifetime. Traditionally the class handled a lot of things like loading the file, repeatedly checking if the file has changed, is the right version of the file loaded etc. We also load a different set of files for test cases to ensure that it is working fine. All this was done very un organized fashion earlier. Every one created their own version of the file. There were lots of versions of these files and they were un manageable. I introduced a subsystem that will load you the right file(do the version verifications) given a name and a configuration that will tell all the versions of the file available. It eventually ensured that only two to three versions of the files are used across all the test cases. It basically follows a facade and factory pattern where the loader will create the right file object, which will have interface to load, save and should_reload. It was eventually even used to load contents from CouchDB as they only represent a document. This is now too complicated for the developers and no one really reads the code or the documentation I wrote. I do agree that going back to our old system will remove one sub system but will bring back the problem of un manageable number of files.

At this juncture I find myself quite unsure of all the things I have learnt. I find myself not really interested in suggesting any improvements as my solution will only be accused of being too complicated.

What do you think I can do at this point in time?