Depending on abstractions, creating single-responsibility classes, and writing unit tests are not exact sciences. It's perfectly normal to swing too far in one direction when learning, go to an extreme, and then find a norm that makes sense. It just sounds like your pendulum has swung too far, and might even be stuck.
Here's where I suspect this is going off the rails:
Unit tests have been an incredibly hard sell to the team as they all believe they're a waste of time and that they're able to handle-test their code much quicker as a whole than each piece individually. Using unit tests as an endorsement for SOLID has mostly been futile and has mostly become a joke at this point.
One of the benefits that comes from most SOLID principles (certainly not the only benefit) is that it makes writing unit tests for our code easier. If a class depends on an abstractions we can mock the abstractions. Abstractions which are segregated are easier to mock. If a class does one thing it's likely to have lower complexity, which means it's easier to know and test all of its possible paths.
If your team isn't writing unit tests, two related things are happening:
First, they are doing a lot of extra work to create all of these interfaces and classes without realizing the full benefits. It takes a little time and practice to see how writing unit tests makes our lives easier. There are reasons why people who learn to write unit tests stick to it, but you have to persist long enough to discover them for yourself. If your team isn't attempting that then they're going to feel like the rest of the extra work they're doing is useless.
For example, what happens when they need to refactor? If they've got a hundred little classes but no tests to tell them whether or not their changes will work, those extra classes and interfaces are going to seem like a burden, not an improvement.
Second, writing unit tests can help you to understand how much abstraction your code really needs. Like I said, it's not a science. We start off badly, veering all over the place, and get better. Unit tests have a peculiar way of complementing SOLID. How do you know when you need to add an abstraction or break something apart? In other words, how do you know when you're "SOLID enough?" Often the answer is when you can't test something.
Maybe your code would be testable without creating as many tiny abstractions and classes. But if you're not writing the tests, how can you tell? How far do we go? We can become obsessed with breaking things up smaller and smaller. It's a rabbit hole. The ability to write tests for our code helps us see when we've accomplished our purpose so that we can stop obsessing, move on, and have fun writing more code.
Unit tests aren't a silver bullet that solves everything, but they are a really awesome bullet that makes developers' lives better. We're not perfect, and neither are our tests. But tests give us confidence. We expect our code to be right and we're surprised when it's wrong, not the other way around. We're not perfect and neither are our tests. But when our code is tested we have confidence. We're less likely to bite our nails when our code is deployed and wonder what's going to break this time and whether it's going to be our fault.
On top of that, once we get the hang of it, writing unit tests makes developing code faster, not slower. We spend less time revisiting old code or debugging to find problems that are like needles in a haystack.
Bugs decrease, we get more done, and we replace anxiety with confidence. It's not a fad or snake oil. It's real. Many developers will attest to this. If your team hasn't experienced this, they need to push through that learning curve and get over the hump. Give it a chance, realizing that they won't get results instantly. But when it happens they'll be glad they did and they'll never look back. (Or they'll become isolated pariahs and write angry blog posts about how unit tests and most other accumulated programming knowledge is a waste of time.)
Since making the switch, one of the biggest complaints from developers is that they can't stand peer reviewing and traversing dozens and dozens of files where previously every task only required the developer touching 5-10 files.
Peer review is a lot easier when all of the unit tests pass and a big part of that review is just making sure that the tests are meaningful.