So the question was:
Is this actually a common practice or in any way a good idea?
Among the currently available answers is a resounding no. So there is few other things I could chime in about it such as; even procedural code can be made modular and including everything but the kitchen sink is not how you achieve modularity. Which one giant class split into partials does do, it all adds up into one big mess.
However that question is a red herring to the real critical part what has been missed; as the OP also has the following to say about the situation:
(...) While my gut reaction was to nuke it from orbit, they insist...
(...) I'm inclined to take immediate steps to bring this beast down (or at least prevent it from growing further) but I'm willing to believe I'm wrong.
HOLD YOUR HORSES!
This here is something that would make my figuratively speaking monocle drop into my figurative cup of tea.
I've been in similar situations and let me do tell you: DON'T fall for the urges to do so. Sure, you can drop the Nuke Hammer of Justice on the team but before you do so please humour yourself with the following bit of conundrum:
What will happen if you tell the team that their code sucks and to sod off?
(...or something like that but less offensively, it doesn't really matter because they will be offended regardless what you do if you decide to go full force on them)
What is the current situation with the code base? Is it working? Then you'll have big problems explaining to their clients that their code essentially sucks. No matter what reasons they have: as long as it is working, most clients don't care about how the code is organized.
Also put yourself in their shoes, what would they do? Let me amuse you with the following very possible outcome:
Team Member #1: "So there is this guy telling us that we've been doing it wrong for the past years."
Team Member #2 and #3: "What a jerk."
Influential Team Member #4: "Don't worry about it, I'll just go to the management and report it as a harrasment."
See what Influential Team Member #4 did there? He went to the management and reduced your karma in the company. He might be American-Italian, telling everyone to not worry about it, but then I'd be racist about it.
Painting the offending team into a corner with letting them admit that they did it wrong for so long is also a bad idea and lead to the same thing. You'll lose respect and some office politics karma.
Even if you managed to get a bunch of people to sign off on this, in order to "teach the team a lesson", remember that you're doing this to fairly smart people who apparently get some things done. Once the code will be rewritten/refactored/dealt/whatever'd with and problems arise that you will be held accountable as you were the firestarter.
Being adversarial about situations like this is mostly a lose/lose game as it risks to become a vicious circle of blame games. This is a suboptimal outcome for this situation. Even if you win, you're suddenly handed over the mess that someone else did.
There are Other (Much Mature) Ways
I was in a similar situation once, but then I took an arrow in the knee. So after a while with that sudden career altering arrow in my mind I got a book Driving Technical Change by Terrence Ryan. It lists several patterns of skeptics, the kind of people don't act on good ideas. They are all most likely applicable in the OP's case:
- The Uninformed - They genuinely did not know there are other ways or simply didn't understand. Junior developers usually fit this category but not necessarily. (To be honest: I've met junior developers that would be more brighter than this.)
- The Herd - They knew better techniques than using partial classes but didn't know that they were allowed.
- The Cynic - They just like to argue that having partial classes is better than your idea just for the sake of arguing. It's easy to do that in a crowd instead of standing in front of a crowd.
- The Burned - For some odd reason they don't like to create new classes, most likely they perceive it as too difficult.
- The Time Crunched - They're so busy that they can't bother to fix their code.
- The Boss - They think: "Well it works; so why bother?"
- The Irrational - Ok, they're just completely crazy.
The book goes on with a list of strategies and so on, but in the OP's case it's a matter of persuasion. Going head strong with facts on the anti-pattern is not enough.
If it is in your interest to increase code quality, at least give the offending team chances to reiterate and rectify their own mess. Personally I would try to sway them by listening and asking leading questions, let them tell their story:
- What exactly is their god class doing?
- Have they run into any problems? Do they have any bugs? Suggest sane fixes without telling them to do so.
- If you a user of this god class as an API: Are there simpler ways to use the code than to use the whole thing? Suggest simpler examples, see how they react.
- Can you switch out some functionality with another, without having to write the function?
- Are they in need of some training? Can you convince management to give it do them or have lunch meetings about patterns and practices?
... and so on. Give them small suggestions so they can move forward. It takes time and will need some office politics grade elbow grease but patience and hard work is a virtue right?