Unless there's a specific reason you'd need (want) to process the data in a `State` you should probably stick to Ashley's own `EntitySystem`. Without you yourself expanding the functionality of `State`, `EntitySystem`s are for sure more flexible, as in you can tell it to not process the system, you can do something when it's added / removed etc. 

Also the development team for Ashley probably optimized their framework as much as possible, meaning that even though it might be a small increase the `EntitySystem`s are probably faster.

If you wish to use Ashley together with GdxAI's States perhaps you could implement it by creating a `Component` and `EntitySystem` that handles the states for you:

 // Component example
 public class StateComponent<T> implements Component {
	 private State<T> state;

	 public StateComponent(State<T> state) {
		 this.state = state;
	 }
 // Other methods omitted for clarity.
 }

<code split hack lol/>

 // System example
 public class StateSystem<T> extends IteratingSystem {
	
	 private YourCustomStateMachine machine = new YourCustomStateMachine();

	 public StateSystem() {
		 super(Family.all(StateComponent<T>).getFamily());
	 }
	
	 @Override
	 public void update(float deltaTime) {
		 super.update(deltaTime);
		 // Make sure to update machine in the update() method so it only 
 // runs once per frame and not once per entity.
		 machine.update();
	 }

	 @Override
	 protected void processEntity(Entity entity, float deltaTime) {
	 	//Process the entity and update states as usual.
	 }
 }

For a more generalized question on `Finite State Machines` and `Component Based Programming` see [this question][1].


 [1]: http://gamedev.stackexchange.com/questions/24603/how-to-wire-finite-state-machine-into-component-based-architecture?rq=1