"As small as possible" (DB partitions, message size, μsvcs, Bounded Contexts, class names, method arity, ...) is almost universally bad advice in software design. Some critical logic is going to cross those boundaries and result in poorly implemented, preventable workarounds.
But, "Whenever something is wrong, something is too big" (Kohr 1957) is also true for software. Big things are more obviously bad. Small things look simple, because the wrongness hides not inside the things, but in their connections.
Things usually tend to get bigger, rarely smaller or stable. @CarloPescio calls this gravity (things with mass acquire more mass) in the Physics of Software. Our usual reaction is to advocate smallness.
And then "make it small" becomes misinterpreted as "make it as small as possible". Simple rules are so much more comfortable than networks of fallible competing heuristics.
"Just right" is one answer, but it's a meaningless phrase without the tools to define it.
Abstractions are another answer. Unless they're bad. Then they're harmful. "Bad abstractions are bad" becomes "Abstractions are bad".
(If you've read this far, sorry, no solutions tonight. It's Sunday, I've got a loaded kindle, and someone gave me a nice 19yo single cask scotch for christmas.)
