Being able to tightly define what part of your app is impacted if one of these fail and restore it before the rest of the app is impacted is a game changer.
OTP also deeply force you to think of how you start and how you stop these, taking dependencies into account. It helps in cleaning up stuff.
I guess i'll have to try OTP one time to understand why so many people rave about it. I only know one guy who had made real work with erlang / otp and he told me it was beautiful, but not quite as relevant anymore, because of k8s. But i guess i need to make my own opinion.
With respect to user data, a supervised process can crash and the supervisor can restart with the last known good state of that data. It requires some thought on the part of the developer to achieve this, but it's really powerful.
Plus some 3rd party APIs are rather terrible and if you end up re-sending a request (because your server/container went down after the request got sent to the API, but before the response got back/was processed) then the 3rd party API could end up in an inconsistent state.
I wonder if there are other patterns like that.