IMO, it's a good question. Beginners wouldn't even think of asking something like it, and prefer solutions that don't involve having to design reusable classes and OOP encapsulation and things like that. To be realistic, you don't need scalability and deliberate architecture for everything.
But seeing your move list, I have a hunch that you will need a little bit of it.
And it's true, there are a lot of ways to do it. You'll probably end up trying different things and seeing what works and what doesn't anyway, but instead of answering your questions individually, let me explain a whole recommendation.
A model-and-view setup is really helpful. This setup is kind of what Mechanim follows (for the most part anyway).
Basically: Mechanim actively watches values you tell it to watch (in the recommended setup) then decides what animations to play.
So in a Model-And-View setup.
One script handles the Model: It should encapsulate all the game logic of the character, interacting with game rules and the world and stuff like that, and keeping all the character's stateful variables. Ideally, this script should have NO IDEA that you're using Spine. It should not try to talk to Spine.Skeleton, Spine.AnimationState or SkeletonAnimation at all.
Another script handles the View: This is your own Mechanim. It should interpret and react to changes in the Model and show it visually, in this case by playing animations through the Spine objects. At the same time, the View script is aware of what Spine is doing so it only plays animations when and how you want it to, according to the state of both the character logic and Spine's animation. By placing this in a separate script, you can manage your animations better. And trust me, as your character has more and more moves, it can get really messy if animation logic gets mixed up with game logic. It also allows you to scale up to fancier things (like the transition stuff that Mechanim is capable of)
One relevant point about the View script is that (while it has different implementations), it's usually a change detector:
The View script should be able to tell when there's a relevant change in the character Model's state, and then play appropriate animations when that happens.
Change detection can be through (1) polling/checking bools and numbers on the Model while keeping track of the previous values, (2) the Model actively informing the View of any changes through callbacks or actual method calls to the View's methods, or (3) some mixture of both.
So to answer your question: yeah, it likely has an Update() that keeps checking if something changed, and interpret it accordingly a change is detected.
Another thing to note though is that your character likely has stable and non-stable states, with corresponding looping and non-looping animations. You likely have to handle those in two different ways.
Then you have to work out some kind of hierarchy for animations for the View script to abide by. This is equivalent to building the State Machine in Mechanim. For example, the logic can go: If the character attacks, play the attack animation once. After it's done playing the animation, let it check if the character is blocking. If he's blocking, just loop the blocking animation. If the character stops blocking, check if the character is walking. If he's walking, play the walk animation. If not, play idle.
It may be helpful if you draw this as a diagram on paper to map out how you want it to work, and then run the game and try getting your character into different situations to find unexpected, complex cases.
Just note, if you're an OOP purist, that especially in games, there will always be some intermingling between these two responsibilities (some people want it so that game-logical colliders follow what the image looks like, or timing needs to come from animation data. There are always pros and cons to how you wanna do these things.) How much of that "impurity" or violation of this separation of concerns you want is really up to you. Just know, for performance and maintainability reasons, that it's always there.
You should also hit up @Mitch. He demoed something for Spine-Unity that does some of the things Mechanim does. Not sure what happened to it though.
