If you are starting from scratch (again), you can make good monolith too, since you already know a lot about the problem you are solving.

The issue generally isn't just creating something clean but rather it's maintaining something clean. Something that will be owned not by you but by multiple teams whose members change over the course of years.

On a side note, I've found that creating something again usually leads to messes as you try to fix all the issues in the original which just creates new issues.

This seems to always be the case when two alternatives are discussed on HN. The new and shiny is muddled with the new design, so it's hard to tease out where the improvement came from, and in most cases, the new design is possible in the old and trusted.

The point stands. If you can create good interfaces over a network, you can create good interfaces over function calls too.

The difference you miss is that the former discourages bad interfaces and the latter does not. There is no "you" in most businesses. There's dozens of people who changes over time. People with deadlines and concerns of their own.

> the former discourages bad interfaces

That does entirely depend on your language and tooling.

> the latter does not

And that does entirely depend on your processes and internal communication.

If your people keep changing, your chances are much less astronomically bad with a monolith.