One can usually look at the scope of a project up front and determine whether or not modularization would be beneficial, especially in larger projects where multiple teams or squads are working on features simultaneously.

From my perspective, I agree with the premise that we should always question our preconceptions. But over the years we've managed to accumulate a large body of knowledge concerning the software development process and we tend to know what works, what doesn't, as well as a plethora of things we should usually avoid.

But I'd also argue that breaking rules just for the sake of breaking them is just as bad as blindly following them.

Bottom line is that if you know WHY you're doing something, and WHY the rule is structured in the way that it is, then you're in a good position to determine if it applies in your particular case.

And if you can make a solid case for breaking it, then go for it.