Thanks, good food for thought!
The transactional fallacy is when you model something as a transaction while it really is a process. In Clojure we are perhaps even more susceptible to this because we tend to model things simply as functions. A web service call, a database import, a HTTP handler which in turn consults several microservices, they all just become functions. When you call such a function all you can do is wait for it to finish or blow up.
I watched Avdi Grimm’s talk, and it’s awesome. However, bringing his ideas fully to Clojure development maybe a complication as they seem to be somewhat redundant within Clojure’s paradigm.
To see distinction between momentary, and continuous things is important. That is certainly an important lesson to take from his talk. However, in Clojure terms it still looks like this:
Ask yourself about how granular you need your data stages (states) to be, and write your functions accordingly. Which is not a new idea, anyway 
As I see it, one of the Clojure’s advantages is emphasis on data in modeling: here’s starting point, here’s what you need to get, now just insert transformations inbetween. It is exactly what it makes architecture planning in Clojure so much easier, and way more natural then with majority of other languages.
And from this perspective distinction between transaction, and process fades.
A process is (I suppose) a continuous application of a function(s) producing Nth state from (N-1)nth, maybe invloving some sort of logically unified chained dispatching from fn to fn based on state properties at every step. Transaction is probably just one-step application of a function. Simply functions, nevertheless if your state keeps information so that it allows you to distinguish between stages you’ll be fine adding progress bar, or resuming after failure with ease.
Grimm tries to solve issues brought by actions-first approach, I believe.
