Another sub-point on your point is that restarting a process after failure can reduce the number of code paths that need to be handled after errors. Instead of

Another sub-point on your point is that restarting a process after failure can reduce the number of code paths that need to be handled after errors. Instead of having to handle multiple possible error paths and create multiple recovery methods to fix up state, it’s often simpler to crash and re-use the main initialization route to do the recovery. This way you end up with one well known and tested "initialization route". To build on your example, I’d imagine it’d be simple to have a check that compares the current revision of the cached data against a global version or timeout. Then if this check fails you just crash and allow the supervisor to restart the process. The regular initialization path will load the data from the database.