Whether you want your code to be more modular is an opinionated decision but most people don't realize the benefits of high modularity. Almost all major design mistakes that necessitate code rewrites come from lack of modularity.
The instinct seems to be that they want hinges in their code, so their code can adapt and be reusable between projects. But they don't actually know where the hinges should go, because they don't need them yet. So they just put hinges all over the place - even where hinges aren't useful. If the metaphor is confusing, I'm talking about things like making an interface around a class, when there's only one implementor of that interface anyway. Or breaking a complex function into small, "reusable" pieces spread over multiple files - except where those small pieces are only ever used by that one call stack anyway. (And where they aren't that semantically self contained.) The result is harder to follow code with no actual benefit. And the resulting code is almost always bigger and more complex, and thus harder to work with.
Usually code thats the easiest to refactor is code thats the easiest to understand. That means, small, dense, correct code, with a simple test suite. If you write code knowing that you can (and will refactor) later anyway, the result is almost always better software. You will come up with a better design after you know more about your problem domain. Plan for that, and set yourself up to take advantage of that knowledge later.
More likely you think it's a bad thing because your code isn't actually modular. Likely you need one piece of logic but that logic isn't modular so to move it to another location you need to drag a bunch of extra baggage around with it. You wanted a banana but instead you got the gorilla holding the banana and the entire jungle. Sound familiar?
The smallest primitive that is modular is a pure immutable function. If the modules you are moving around are not pure functions then likely your code isn't actually modular.
I understand why you think that type of modularity is bad, but it is actually good. It only appears bad because most of the "modularized" code is only used once.
No one can predict the future so the way to minimize rewrites is to make composable units of code that are small and highly modular. It's not about breaking up your code. It's about writing small logical component then building up the larger component by composing the smaller components.
This results in a large number of modules that are only used one time, but it prepares your code for the inevitable point of the future where you find out the design was wrong and you have to rearrange the logic.
When such a time comes you most likely just trivially rearrange some of your logic and add additional pure functions into your pipe line for any actual new logic. The majority of your modules remain untouched and this only seems bad, but it prevented a rewrite of the entire framework.
The timeline where the definitively worse outcome occured didn't happen because your code was too modular. So you have no point of comparison and you assume the modular code that is hard to read is bad only because it's hard to read. You failed to see how it prevented a massive refactor.
Usually if code is so unmodular, people just live with it and keep accumulating massive tech debt on top of everything. If all your seeing is tiny functions everywhere then this is definitively better than the alternative.
From a design perspective highly modular code is always better. From readability perspective though, you are right, modular code is harder to read. But there are ways to mitigate this.
