Actually, there were several problems with your implementation.
The Wait action does not put the whole event sheet on standby for the supplied duration. It only queues the actions that come after it in that event block (and subevent blocks that branch from it) to be executed after the delay. The rest of the event sheet runs normally while you're waiting for the queued actions to execute.
You had events that queued the walking animations to start after 0.1 seconds, and your 'attack' event only started the attack animations when a 'on any animation finished' trigger was fired. This was wrong for two reasons:
1) Let's say that the enemy is already walking left and on a certain tick you enter the 'chase' event and the enemy is still to the right of the player. That would satisfy the criteria for the event that queues the walking animation (which was already playing) to start again after 0.1 seconds. Let's say that on the very next tick the enemy bounding box is overlapping the player bounding box. You stop the walking animation, but since ticks normally take between 0.02 and 0.016 seconds, you still have a 'start walking animation' action queued (several, actually), so when the 0.1 timer is reached, the animation starts again. Since your 'attack' event only starts playing the attack animations 'on any animation finished', it has to wait until the 'fresh out of the queue' walking animation ends before starting any attack animations, which caused your problem.
2) If you had started using Wait correctly to fix that, you would have still had problems because you stopped the walking animation within the 'chase' event, so the 'on any animation finished' trigger subevent on your 'attack' event would have never fired (triggers as subevents only fire if their condition is met while inside their parent event). In fact, if you disabled the Wait actions in your solution, the enemy got stuck at the end of a walking animation even if it was in attack mode.
Aside from that, you were using wait every tick, when what you intended (I assume) was for the enemy to wait only the first time he found himself out of the player's range (that's why I used Trigger Once in the attached solution). You were also restarting the walking animations every time you did that, which would have looked awkward when you started using real sprites. The sensible choice there is to have the walking animation loop and only stop on command.
The 'direction' variable was necessary in order to use the waiting animation* properly, because you only begin movement when the waiting animation is over, so you need some way of knowing the direction the character has to walk to when the 'on enemywait animation finished' trigger fires. The only alternative would have been to place the trigger inside each of the events which compared the positions of the bounding boxes, which is a bad practice because you have to duplicate actions and that is never a good idea.
The event you were using to change back to chase mode was also a bit flawed. It worked, mind you, but it was confusing since it bounced the enemy back to chase mode even if he was still in the player's range, which would bounce him right back to attack mode. This could have caused you problems in the long run if you ever wished to add more complexity to the enemy AI.
I don't know if I'm missing something, but I'm guessing you can understand now why your approach wasn't working as intended.
Cheers
*: you can replace it with a Wait action in the solution with very few modifications. I still don't recommend it, I find that using Wait is less clear, and you can use the wait animation to have the enemy look confused or whatever, so it's an added bonus