Code style is indeed very important for overall readability, and part of code style means being consistent with said style, even to the extent of respecting the original intentions of the coder that created it or completely redoing it entirely. However, refactoring code is notoriously difficult, and even moreso with projects that have had many project owners over several years.
This is why it is very important that the general practice of you following the style of the rest of the program. Think about it for a second, would you inherit a project with inconsistent coding style and structure had every programmer that worked before you followed this simple rule? No. And since it is easier to add code that follows the general code style of the rest of the program than to refactor, best practice talks about preventative practices, not how best to refactor an already inconsistent project.
That said, you typically don't see articles written about why it is important to be consistent in your code style because it is sort of a given. It would be like writing an article describing why the god object anti-pattern should be avoided whenever possible. Obviously you are likely going to continue your project as you tend to write it, but others may not necessarily do so, so really if you inherit an inconsistent project, it's already too late on that front.
My advice to you would be to get a feel for the different code styles in your program, and pick the one most used in your program and/or the one that is the most straightforward. Then, whenever you need to touch up a class that doesn't quite follow this norm, make a point to ask more time to make the change so that you can make an effort to refactor that class. You'll eventually have something that is consistent throughout, and should another programmer take over your project, we can only hope that they'll continue where you left off.