This is indeed unacceptable! Are you using SkeletonAnimation, SkeletonGraphic or SkeletonMecanim? Could you please describe how you instantiated your objects - was it via prefabs that are instantiated (I assume so) or via SkeletonAnimation.NewSkeletonAnimationGameObject()?
I will have a look at it, however any info on the subject will speed up the process of resolving this issue - so if you could create a zipped package of a minimal Unity project that shows this problem and send it to contact@esotericsoftware.com, that would be very helpful!
I have profiled some stress tests and have on the one hand seen many but very small allocations (for the Bones), where all allocations for 60 simultaneously instantiated Spine-Raptors took 0.5 ms in total.
Are you really getting 25ms from a single instantiation? Or do the 25ms come from GC.Collect calls, which might be due to other larger allocations of your game being cleaned up? Maybe there is a problem somewhere else hiding in the shadows, since the small allocations would not cause any fragmentation issues.
Right now we're solving the problem by "prewarming" and pooling the death animations just after the level is loaded, but it's dirty workaround.
Prewarming of an object-pool is a perfectly valid way and pretty common as well, especially in Unity due to it's 'suboptimal' garbage collector. Allocation-wise you will be able to predict much better how many instances of each object will be active at any time than any framework could. Plus creating vertex buffers of the proper size, etc will always take it's time and should be moved to load-time of a scene as much as possible.