I think you're too quickly dismissing the potential benefits. From the FAQ[1]:
The combination of all the above properties, plus the fact that I/O is also separate from pure computation and updates, enables a number of features that are not found in conventional languages.
The first one is the ability to "replay" the execution of a Cell program. One can easily reconstruct the exact state of a Cell program at any point in time. Obviously that's very useful for debugging, but there are others, more interesting ways of taking advantage of that. It's for example possible to run identical replicas of the same Cell process on different machines over a network, and that's something that will be crucial in Cell's future network architecture.
The second one is orthogonal persistence, that is, the ability to take a snapshot of the state of the application (or part of it), which can then later be used to create with minimal effort an identical copy of it, that will behave in exactly the same way. In Cell, you don't save your data the way you do it in conventional languages. Instead, you simply declare which parts of your application's data structures have to be persisted, and the compiler generates for you all the code needed to save and load them.
Is it as robust as using a mature technology like SQLite? Obviously, no. But these are interesting ideas that lead somewhere new.
When you want quick response to keypress, and yet app state also depends on high-latency ML pose or gesture analysis waiting on camera frames, and spoken "Launch the missiles!" can become "Lunch is mussels! In butter!", replay with improved understanding of past input is nice.
[1]: https://www.cell-lang.net/faq.html