At this risk of sounding old, this feels like repacking all the ideas from thirty years ago about lowering coupling and raising cohesion of services.
Serverless; microservices; Enterprise Java Beans; CORBA services; Remote Procedure Calls; or even RESTful interfaces are this idea that, for the subset of problems possible, the right answer is to make a tight, highly cohesive, low state or stateless block of code. The less callers need to know about blocks of code, the better. Also, the less the blocks code need to know about anything but themselves, the better.
Some problems are trivial, leaf nodes of your call tree: accept a login token; get the product name given a product id; etc. These are stateless, short-lived, and call nothing. Some are orchestrating calls, but can be tricked into single chains of state. Mostly, its all about good design.
Stateless appears to just emphasize the value of having no or trivial state and that blocks of code shouldn't know about the processor unless it important to its purpose. For the moment, there is a huge set of code that assumes long running processes to add state to inherently stateless protocols. I expect that there will arise easier to compute tradeoffs on the cost of a long running process, the start up costs for a process, and the cost of different coding styles.
Write code cleanly; that is still the goal.