While it's advisable to avoid unnecessary state between steps in a scenario like this, removing all state limits the ability for a scenario to express the intent the author speaks about.
> removing all state limits the ability for a scenario to express the intent the author speaks about.
However, writing them like that means each step moves further away from what it says it's doing. The more you do this, the more you might as well not execute them and go and write more examples.
I'm finding these days that a pairing of .feature to corresponding step definition file allows for fluid language, simple step definition code, and well-compartmentalized messes (as opposed to the big ball of mud that Cucumber step definitions often become). Code reuse can happen through test helper classes that are called from step definitions as needed. (FactoryGirl would be an example of a very generalized test helper class, in my mind -- but more system-specific ones can be handy, albeit one wants to avoid making stateful / complex test helper code!)