I'm surprised the problem was exactly as I originally described it. The animator keyed all the properties, including the ones that didn't need to be keyed.

One optimization is to remove those timelines since they're doing nothing.

I'm attaching the edited Spine file. I hope you can open it yourself to see what I mean.
https://www.dropbox.com/s/v8d14bu29a1nehi/Felix-edited.spine?dl=0

In any case, while your animator may have done something that was not necessary, those Spine animations were not likely to be the source of the spikes. This is wasteful, but there are so few bones and 13 instances is so small, that it's very far from being a likely performance bottleneck. Much less a source of spikes.

Based those screenshots it looks like whatever you hooked up to the "Skeleton - Update" profiler item, or how you hooked them up may have been the source of those 200ms spikes.

But I'm currently talking to Nate about how to communicate this more clearly in the Editor since a lot of people seem to jump to this conclusion that position, rotation, scale need to be keyed at every point even if they didn't change. There are some quirks to the current implementation of AnimationState that does require exact matching of Timeline items. The next version of AnimationState that's coming in a few weeks does not have this requirement anymore. This ultimately means less overhead. This is the beta version of it for spine-c# (https://gist.github.com/pharan/77c8ab0880c33716acb8)

The sample file I linked above has a version of the animations labeled "clean" which would be sufficient for the new AnimationState implementation. But the current AnimationState requires them to be matched. There is a separate version of those animations labeled "matched" which fulfills the current AnimationState's requirements for mixing that every timeline in one animation should have a matching timeline in the next. They were generated by using the Key Dopesheet shortcut CTRL + SHIFT + L. But for your purposes and at this stage, I don't think it's feasible (or necessary for performance) to change all your animations to do this.

If it's standard practice to key translate/rotate/scale all the time, it's probably for feature-film/pre-renderered stuff. Regardless of the system, it is wasteful in the context of realtime (not pre-rendered) animation. eg., It would also be wasteful if you did it in Maya/Blender/3dsmax and exported their animations for use in Unity.

But, again, it's not a likely source of a bottleneck. It does make the dopesheet harder to understand. If that's not an issue for your animator, then it's mostly harmless.

At the very least, if you know you're not scaling anything, there's no need to key scale.