> Doesn't this just move the hard part, the maintenance, configuration and understanding, to a different (and equally complex) abstraction layer?

That's true indeed, but I find it more manageable that way.

To me, managing independent processes instead of threads is especially powerful when the lifecycle of the concurrent work can vary.

A typical example that happens quite often is when you have some kind of producer/consumer application. Say, you need to receive some data from a socket, and then process it.

If implemented with threads, it becomes quite messy very fast. You end up with a big blob binary that spawns whatever the hell it wants and need to engineer some complex configuration file to tell it how many workers you want, etc. You also need some notification to this process to tell him to increase or decrease its amount of workers, etc.

With independent process, it can be much more manageable. You can have a "collector" process that reads the socket and places messages in a shared memory, and if you want more/less workers, you just spawn worker processes to read from the shared memory.