Maintainability is rarely created by one architectural choice. It emerges from hundreds of small decisions: whether a name explains intent, whether a function has one job, and whether a dependency is introduced because it solves a real problem.
Good boundaries reduce the amount of context needed to make a change. A module should expose a small, deliberate interface and keep its implementation details private. When boundaries are clear, refactoring inside them becomes safer.
The most valuable code is often unsurprising code. Familiar patterns, explicit data flow, and useful tests allow the next engineer to work confidently. Cleverness can save a few lines today while charging every future reader interest.