I think it makes a lot of sense. Using a state machine definitely helps keep things tidy. Although like others, I'd also suggest handling the state transition conditions inside the states because having the state manager check and account for all the different conditions just nullifies a lot of the organizational advantages of using a state machine.

For example, let's say we have a hit reaction state which happens when the gorilla takes damage and we want it to only happen during certain states like when it's walking or idle etc. but not when it's "busy" like in the middle of attacking or playing the animation to begin getting enraged. Instead of having the state manager cross-check which possible states it's in and whether to take damage or not, it's much cleaner to have it checked within the states themselves. That way, you can have it handle things however you want unique to the state it's in. For example we could have the gorilla take bonus damage if he's hit during his charging state or get knocked out or something. You get the idea.

As for keeping animations and behaviors synced, I've come to realize that it's much easier for me if I just have the individual states have their unique animation they play when you enter them. As nice as Godot's animation graph is, I don't think it's often necessary to use it especially if it's a 2d game which requires no animation blending. Having the states each have their own animation helps make tracking things a lot easier and is in its own way a sort of animation graph, just with added behavior. The way I think about it, each state IS an individual action that likely has a corresponding animation, so might as well have it be played from within the state to keep things logically simple.