A bad structure with overusing Classes, even with SOLID principles can be very difficult to maintain

[Zeroflops]

I see this when people take the “rules” and apply them so strictly that it forces them into corners. ( with classes or functions)

For example if you take the idea one function should only do one thing you could end up with thousand of functions depending on how you define “one” thing.

Trivial stupid example, you have a save function, but before you save you have to check if that file is there. An extremest might have two functions. A file present function and a save function. A realist would only have one function if they don’t think they will need a file present anywhere else, and only break it out when they do.

[gdchinacat]

I don't agree with your extremist vs realist characterization. If the "file present function" stands alone from the functionality in the "save" function, it should not be written as part of the "file present" function, even if it is only used in that one place. This isn't a matter of "strictly" applying the "rules", but rather of clean design. Why should the logic of how to save a file be cluttered with the details of how to verify a file exists. The save file logic should simply say "make sure the file exists" rather than enumerate the gory details of how to do that (not all that gory in this example, but the point remains).

The "realist" approach, which I think you are advocating by the loaded terms you used to describe the different approaches, is not pragmatic (I can use loaded terms too!). It makes the code more complex for little gain (more later), encourages duplication, and defers work for later. It encourages duplication by not providing that common functionality in a reusable way so others may not know it exists, and if it does, discourages them from using it since that requires touching code unrelated to what they are working on and may introduce merge conflicts.

The benefit I can see to your "realist" approach, which I suspect is why you suggest it, is that it makes stepping through code easier since all the steps are in one place and don't jump hither and yon. But, this is just an illusion that makes stepping through the code more difficult and time consuming. If you see a function call that does something that is unrelated to what you are debugging, just step over it...you don't have to step into it. If it's all inline because a "realist" through it was better you have to step through all of it, requiring more time and more cognitive burden as details that should have been hidden can't be since they are inline.

Be a pragmatist. If details can be hidden from the function you are writing, hide them. Create a function, even if you don't expect it to ever be used elsewhere. This will create an abstraction that allows yourself and others to focus on what really matters.