>Tasks that used to take 5-10 files can now take 70-100!

This is a lie. The tasks never took only 5-10 files.

You are not solving any tasks with less than 10 files. Why? Because you're using C#. C# is a high level language. You are using more than 10 files just to write hello world.

Oh sure you don't notice them because you didn't write them. So you don't look in them. You trust them.

The problem isn't the number of files. It's that you now have so much going on that you don't trust.

So figure out how to make those tests work to the point that once they pass you trust these files the way you trust the files in .NET. Doing that is the point of unit testing. No one cares about the number of files. They care about the number of things they can't trust. 

>For small to medium size applications, SOLID is a super easy sell. Everyone sees the benefit and ease of maintainability. However, they're just not seeing a good value proposition for SOLID on very large scale applications.

Change is hard on very large scale applications no mater what you do. The best wisdom to apply here doesn't come from Uncle Bob. It comes from Michael Feathers in his book Working Effectively with Legacy Code.

Do not start a rewrite fest. The old code represents hard won knowledge. Tossing it out because it has problems and isn't expressed in new and improved paradigm X is just asking for a new set of problems and no hard won knowledge. 

Instead find ways to make testable your old untestable code (legacy code in Feathers speak). In this metaphor code is like a shirt. Large parts are joined at natural seams that can be undone to separate the code the way you'd remove the seams. Do this to allow you to attach test "sleeves" that let you isolate the rest of the code. Now when you create the test sleeves you have confidence in the sleeves because you did this with a working shirt. (ow, this metaphor is starting to hurt).

This idea flows from the assumption that, like in most shops, the only up to date requirements are in the working code. This lets you lock that down in tests that allow you to make changes to the proven working code without it losing every bit of it's proven working status. Now with these first wave of tests in place you can start making changes that make the "legacy" (untestable) code testable. You can be bold because the seams tests are backing you up by saying this is what it always did and the new tests show that your code actually does what you think it does.

What does any of this have to do with:

>Managing and organizing the massively increased number of classes after switching to SOLID?

Abstraction.

You can make me hate any code base with bad abstractions. A bad abstraction is something that makes me look inside. Don't surprise me when I look inside. Be pretty much what I expected. 

Give me a good name, readable tests (examples) that show how to use the interface, and organize it so I can find things and I wont care if we used 10, 100, or 1000 files.

You help me find things with good descriptive names. Put things with good names in things with good names. 

If you do all this right, you will abstract the files to where finishing a task has you only depending on 3 to 5 other files. The 70-100 files are still there. But they're hiding behind the 3 to 5. That only works if you trust the 3 to 5 to do that right.

So what you really need is the vocabulary to come up with good names for all these things and tests that people trust so they'll stop wading through everything. Without that you'd be making me crazy too.