Stateless code seems easier to test and operate, since it's basically just a function. Certainly, it can affect the world around it (e.g. in a database), but it's a long-lived object that performs a function, and this is pretty simple.

The downside is that the results of the action require a separate object to describe, requiring either an inner class to help manage or coupling between two classes.

This can also lead to architecture astronautics if you try to generalize the result class.

Stateful, on the other hand, keeps all concepts together: the operation and its possible results are all in one class, which feels cohesive and easier to manage/evolve the code.

The downside is that the object, once invoked, cannot/should not be invoked again. Thus, you'd probably need some safeguards to help avoid that.

The stateful approach also could be awkward if you wanted multiple "doit" methods. You then get a convoluted object with lots of optional values for results.

The "lazy mode" of these approaches is woerth considering:

lazy devs applying the stateless approach will use boolean return value, which suck

lazy devs using the stateful approach will overload existing objects with more methods.

I believe that the way in which a design decision plays out under stress is important.

Of note, this is why OO books like POODR leave me wanting. The examples are so trivial and unlike anything resembling real code that they fail to give true insight.

You can retcon any set of objects to any domain - this is not helpful at coming up with a good design. And, to restate, "good" means more than just "at rest is it understandable" but "will devs easily adhere to this design under stress”.