> Why we need these careful thought, abstraction and architecture?

your answer focused on maintainability, but you are overlooking what I think is the bigger problem: those components will eventually interact with one another (technically, by nature of living in the same code tree, sharing the same storage backend, framework, common libraries, …, or logically, by referencing the same entities for slightly different and complementary features). With that comes the need to centrally control what they should/can/cannot do. There is no shortcut to having to clarify (with your customer) and formally document what those layered interactions are, or, before you know it, you have multiple incompatible user access controls, row-level access policies, competing master/reference data, or different parts of the application interpreting differently the same data.

It's a pretty bad value proposition, if you ask me, to have to do so much hand-holding for a result that comes with no guarantees whatsoever (you will never know the extent of which your clean spec "made it in").