(Speaker here) We appreciate your concern, the risk is real, and you're right – the hard parts cannot be put off. And we have not put them off. We've already thought through how to implement recovery, resync, long running sessions. We have several wiki pages worth of notes answering questions like how we will deal with network partitions, reconciliation, durable session state, dealing with OS sleep timer state, OTA code updates, etc.
What we have not yet done is the implementation work, because our pilot use case driving our eng priorities – an internal support app for a Series B SAAS startup – does not actually have this theoretical problem you describe. Photon's protocol today is tolerant to arbitrary delays, IFF you can guarantee message delivery and ordering, which is the problem TCP solves. We do already have pending/loading states, which are trapped locally through reactive try/catch.
BTW, the Photon codebase is only 2k LOC (analyzer, compiler & interpreter for JVM and JS targets, standard library) and a substantial part of that is redoing parts of the Clojure/Script analyzer infrastructure.
"truly immense amount of engineering work that goes into making modern web system software appear reliable to users"
That's a bit much for me. The current industry state of commercial SAAS/crud apps is a dumpster fire, Photon's speed and responsiveness is already miles ahead of literally every laggy SAAS tool we all suffer where programmers have manually hand-coded the network in the form of REST calls, manually split HTTP routes, backends-for-frontends, client side ORM, GraphQL resolvers, etc. How often do you Cmd-R your gmail or notion because it stopped working? React.js-era software is rotting to death, "reliable" is not a word that remotely describes my daily experience with web software today.