Read some Program code and something is conspicuously missing. There is no error handling. No retry logic. No checking whether the data has finished loading from somewhere. The code just states what it wants, as if everything always succeeds and arrives instantly.
That is deliberate. Loading, errors, retries, and disabling parts of the interface while something is in progress are cross-cutting concerns: they don't belong to any one feature, but in most codebases they have to be sprinkled consistently through all of them. They bloat the code, they are repetitive, they are written slightly differently everywhere, and they need careful, fiddly testing precisely because they are everywhere. They are also, frankly, boring, and boring code that has to be correct in a thousand places is a bad combination.
In Program these are handled once, uniformly, and mostly invisibly. Because every value already carries whether it is ready or in error, the system can do the cross-cutting work at the place it actually matters, the edge, where a value is shown or used, rather than at every step in between. A region of the interface shows a spinner because something it depends on is pending; it shows an error with a retry because something failed; a control is disabled because a change that would touch the same state is still in flight. None of that is wired by you.
The result is that you get to write the happy path, the simple, legible description of what should happen when all goes well, and the concerns that normally smear across the whole codebase are factored out into the runtime. It is the same move structured programming made long ago: take something repetitive and error-prone, name it once, and stop writing it by hand everywhere.