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

This is the opposite of the single-responsibility principle. To get to that point, you must have divided up your functionality in a very fine-grained way, but that's not what the SRP is about -- doing that ignores the key idea of cohesiveness.

According to the SRP, software should be divided into modules along lines defined by their possible reasons to change, so that a single design change can be applied in just one module without requiring modifications elsewhere. A single "module" in this sense may correspond to more than one class, but if one change requires you to touch tens of files then either it's really multiple changes or you're doing SRP wrong.

Bob Martin, who originally formulated the SRP, wrote a blog post a few years ago to try to clarify the situation. It discusses at some length what a "reason to change" is for the purposes of the SRP. It's worth a read in its entirety, but among the things within deserving special attention is this alternative wording of the SRP:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

(emphasis mine). The SRP is not about splitting things up into the tiniest possible pieces. That's not good design, and your team is right to resist. It makes your code base harder to update and to maintain. It sounds like you may be trying to sell your team on it based on unit testing considerations, but that would be putting the cart before the horse.

Similarly, the interface segregation principle should not be taken as an absolute. It is no more a reason to divide your code so finely than is the SRP, and it generally aligns pretty well with the SRP. That an interface contains some methods the some clients do not use is not a reason to break it up. You are again looking for cohesion.

Additionally, I urge you not to take the open-closed principle or the Liskov substitution principle as a reason to favor deep inheritance hierarchies. There is no tighter coupling than a subclass with its superclasses, and tight coupling is a design problem. Instead, favor composition over inheritance wherever it makes sense to do so. This will reduce your coupling, and thus the number of files a particular change may need to touch, and it aligns nicely with dependency inversion.

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

This is the opposite of the single-responsibility principle (SRP). To get to that point, you must have divided up your functionality in a very fine-grained way, but that's not what the SRP is about -- doing that ignores the key idea of cohesiveness.

According to the SRP, software should be divided into modules along lines defined by their possible reasons to change, so that a single design change can be applied in just one module without requiring modifications elsewhere. A single "module" in this sense may correspond to more than one class, but if one change requires you to touch tens of files then either it's really multiple changes or you're doing SRP wrong.

Bob Martin, who originally formulated the SRP, wrote a blog post a few years ago to try to clarify the situation. It discusses at some length what a "reason to change" is for the purposes of the SRP. It's worth a read in its entirety, but among the things within deserving special attention is this alternative wording of the SRP:

Gather together the things that change for the same reasons. Separate those things that change for different reasons.

(emphasis mine). The SRP is not about splitting things up into the tiniest possible pieces. That's not good design, and your team is right to resist. It makes your code base harder to update and to maintain. It sounds like you may be trying to sell your team on it based on unit testing considerations, but that would be putting the cart before the horse.

Similarly, the interface segregation principle should not be taken as an absolute. It is no more a reason to divide your code so finely than is the SRP, and it generally aligns pretty well with the SRP. That an interface contains some methods that some clients do not use is not a reason to break it up. You are again looking for cohesion.

Additionally, I urge you not to take the open-closed principle or the Liskov substitution principle as a reason to favor deep inheritance hierarchies. There is no tighter coupling than a subclass with its superclasses, and tight coupling is a design problem. Instead, favor composition over inheritance wherever it makes sense to do so. This will reduce your coupling, and thus the number of files a particular change may need to touch, and it aligns nicely with dependency inversion.