Well, if the task is not interruptable a coroutine would work fine. If you want to be able to stop the process at any time a state machine would be better ;). A coroutine is really useful when you have a quite linear command chain.

IEnumerator MoveToTile(Vector3 target)
{
    //Start looping rotation animation here
    while(not facing the the target)
    {
        //Rotate
        yield return null;
    }
    //switch to run / walk animation
    while(not reached target)
    {
        //Move forward
        yield return null;
    }
    //stop the animation / switch to idle...
}

Just in case you didn't know: coroutines are also statemachines but the state-handling is hidden. The compiler even creates a whole seperate desicated nested class for each coroutine. Since the state-stuff is not accessible, coroutines are not as flexible as own statemachines ;)

I'd say that every Update event, the robot should calculate afresh whether it needs to turn or move forward. So a modeless solution. Only if that choice was expensive to make would I use a modal approach. The trouble with the modal approach is that you then need more code to kick it out of the mode (eg. when player chooses new tile before robot reaches first choice).