This is not a God object.
It seems like it is because it's doing so much, but, in a way, it's doing nothing at all. There is no behavior code here. This object isn't an omnipotent God that does everything. It just finds everything.
This pattern has a more proper name: Service Locator. It strongly contrasts with the Dependency Injection* pattern.
Your testablility complaint is valid but the main principle being violated here is the Interface Segregation principle.
Here's why: If I come at this thing with an intent to refactor away the dependency inversion problem I'd just stop hard coding CoreService. I'd replace it with a parameter that must be passed in. Can you see why that doesn't really help?
On top of it being annoying seeing this parameter passed into everything this doesn't actually fix the dependency problem because seeing that an object needs CoreService tells me zero about it's real needs because CoreService provides access to anything and everything. We externalize dependencies to make needs clear.
If we follow the Interface Segregation principle we see that an object that, right now, needs CoreService actually needs maybe 5 out of the 100 things it provides. What those 5 things need is a good descriptive name.
Now when I see that name I know what this thing needs. I can go find ways to provide those 5 things. There might be 2 or 42 ways to provide those 5 things. One of those ways might be through a test, but this idea is about a lot more than testing. Testing just makes this problem painfully obvious.
Another pattern hiding in here seems to be singleton. Dependency Injection has a wonderful alternative to that. Just build what you need in main once and pass references to what you built to everything that needs it. Once you have built your graph of long lived objects call one method on one of them to start the whole thing ticking. Just try not to go nuts. It's OK to break this up with factories and other creational patterns. Just keep creation and behavior code separate.
To convince others you're going to have to start showing how this problem can be fixed. Make some things that express their needs and write code that satisfies those needs. A simple factory with a good name and it's own file to live in often gets this done. If you're stuck with the need to find the rest of their stuff let the factory deal with that problem. Now your object is blissfully unaware of their nonsense and won't care when you get around to fixing the rest of it.