Thanks again, Vincent, for your support!
I see your point about the balance.
Oh! I like your example also because the conversational logic is placed in conversational flow scripting (all needed stories), easily understood and implemented by conversational designers. This moves the logic (slot validation, etc.) ) from the action Python code to the YAML. For me this is a plus in terms of clearness and maintainability.
Viceversa you are right when you say that this “fragments” RASA forms in a multitude (but simple to read) custom actions. It’s a trade-off. On the other side forms are prefect to collect many related slots, forming a consistent data structure (in Python parlance this could be the tuple:
(body_temperature, oxygen_saturation, user_feeling) ).
What about very short forms? You could have a form that just accepts a single slot.
I see, but what’s the advantage comparing to a multi-slots form?
Wait! Back to my initial request (a push-mode that mimics ChatScript gambits), the bot could generate external events each one triggering an event or a single-slot form (corresponding to a question like what’s your body temperature?) in a temporal succession. Maybe RASA session could be used to avoid the conflict?
I have to think about it…
BTW Thanks and my respect for your dissemination work. I also enjoyed your video tutorials. Need more 
giorgio