Sort of a strange question I suppose. But one that's been really relevant to me recently. I've been taking an "Advanced Software Design" class which is really just a codename for Java Software Development class, and found myself frequently disagreeing with a lot of what was being positioned as good design. I think the root cause of it all is abstraction. What does abstraction actually do? It hides details of things. The argument here is that it makes things more composable/reusable. In principle, I think that's great. It's much easier to have a vector type than to reimplement one for each use case. It also simplifies problems significantly. The problem that I run into, and see a lot of others run into, though, is the lack of connection to the reality of the hardware. By hiding the details, we lose out on the context of the problem. And context is very important.
Again, I think abstraction has its place. Mathematics is just abstraction, and it's served us very well. But is abstraction itself inherently good? I would argue that it is not. Some problems require an understanding of the reality surrounding the problem. Operating systems, for example, are constrained by the physical limitations of the computer. To develop an operating system you typically have to eschew or reimplement many of the abstractions you might have relied on with a hosted environment. In trade, you get full control of how that machinery works, which is very powerful. Not all problems need this, but I would argue that more do than don't. Stuff like quick simulations, hacky scripts, learning projects are fine to be abstracted. But when the goal is something useful, either as a product, tool, or whatever, the further abstracted you are from the computer, the worse your software will be. I think the modern internet is the perfect example of this. Abstraction piled on top of abstraction, to solve problems not fundamentally more difficult than the ones we were solving 20 years ago. And yet, the weight of web software is much larger than it was 20 years ago. Did abstracting away the hardware really solve any problems? No.
Two individuals I consider highly in computing are Chuck Moore and Niklaus Wirth. Both have different, yet similar opinions on software design. Chuck Moore is the ultimate hacker. Do exactly what needs to be done, with as little fluff or machinery as possible. Forth and his subsequent iterations on it are very compelling examples of this philosophy. While incredibly difficult to do correctly, once complete the resulting solution is 'perfect'. Chuck would argue that if you need to extend your design later, then you have a different problem than you did originally, calling for a new program. The only abstractions you should use are those absolutely necessary to the expression of the program. Wirth took much more of an engineering approach. He championed simple, lightweight software that worked well within its physical limitations. One of my favorite works of his is Oberon, which is an extremely simple, well designed operating system and programming language. It doesn't reject abstraction, far from it. It's one of the few systems programming languages I'm aware of that is garbage collected (Go doesn't count in this instance, I mean systems in the sense of embedded systems/bare metal). He also supports an object oriented paradigm. These abstractions are implemented in a way that lets you not worry about details, but still exposes the physical reality you're working in. You could still manage memory, and you could stick to strict procedural programming if you wanted.
I'm not super sure where I'm going with this. I'm personally working on a programming language which is honestly pretty abstract. So I'm still figuring out my own opinion on this. But I think it's safe to say that all abstractions should have a definite purpose. I agree with Chuck Moore that if you need to extend your software later, you have a different problem.