Some of these allocations might be caused by how the built-in Spine.AnimationState is programmed.
Some of these are just caused by how Unity's mono works.
One thing you could do is remove mixing since, from the looks of that stack, it looks like GetHashCode allocates.
You can remove mixing by setting defaultMix on your SkeletonDataAsset to 0.
I don't think you're doing anything out of the ordinary (or outside of Best Practices).
Using skeletonData.FindAnimation and then using the return values to set the animation is definitely good. It's what I do all the time. String interfaces irk me, is the thing, though I've yet to see our quick-and-dirty string-filled prototypes hiccup on 2-year-old devices.
But Nate also once mentioned that Spine.AnimationState is kind of just a convenience for what most people need from Spine, and if you need something specific like crazy amounts of optimization so it scales up to the thousands or something, you should rewrite it, remove a lot of the parts you don't need and design it around how you're specifically using it for your game. As it is though, it really hasn't been causing problems for us. Certainly not performance-wise.
You'll get worse slowdowns from badly-keyed animations. The Spine editor is so much more in need of Best-Practices info since animators really won't know how the runtime is put together. They'll have no idea if what they're doing is fast or will cause severe slowdowns.
I have seen some nasty stuff. Keys everywhere and for every thing, every bone and slot and every transform value, for things that don't move. Have enough skeletons and animations like that and you'll suffer performance degradation far worse than what tiny performance refactoring away these allocations can buy you.
Are you at the point in development where it's time to make optimizations?
Do you switch/set animations a lot per frame in-game? Do you have a lot of SkeletonAnimations that do this?
