A good approach could do the following:

• Have the rays on their own separate image(s) parented to a bone in the middle that will rotate (right now they are rotating on their own pivot which is not what you want to achieve)
• Add a 4 vertices clipping as a child of the bone that holds the middle images not rotating, set the clipping so it only affects the rays in the draw order.
  https://esotericsoftware.com/spine-clipping
  If the image in the middle doesn't have to be transparent you may also skip the clipping.

NeOreo If the final output of the animation is intended to be in video format, this is not a problem, but if the final output of the animation is intended to be played back using the Spine runtime, such use of clipping attachments is computationally expensive and is not recommended.
The general approach is to prepare an image that covers the center and hides the image behind it without trying to make the center transparent that way.

while doing some simple mesh deformation

It's almost always better to use bones to deform meshes:
https://esotericsoftware.com/spine-keys#Deform-keys

I've been told to avoid png sequences as much as possible.

Like most things, there's no hard and fast rule. It uses up texture space, but that isn't always an issue. Maybe your developers can accept some texture switches to allow you to use more unique images. See the first 2 paragraphs here:
https://esotericsoftware.com/spine-texture-packer

See the performance page for some details:
https://esotericsoftware.com/spine-metrics#Performance

I'm guessing that duplicating hundreds of bones to make particles can also be heavy on the processing?

Sure, too much of anything adds up. The important thing is to know your boundaries. Consider everything that is being rendered, see how far you can push the number of bones, or mesh deforms, or anything else until it becomes unacceptable. You have to do it yourself, as there are so many variables that every app will behave differently. If your app is doing very little except render a single skeleton, that skeleton can be quite complex and using hundreds of bones is probably fine.

Using hundreds of bones or clipping a ton eats up CPU while other things eat up other resources. Drawing tons of images sends lots of geometry to the GPU and uses up GPU fill rate. You need to push the boundaries in different ways to understand where the limits are for your app.

It also matters what hardware you are targeting, which is something you and your team need to decide on early on.

All that is hard and the results can change -- everything is fine until more stuff is added to the app. Due to that people usually aim for some rule of thumb type voodoo where they avoid some features or use them sparingly without doing any of the work to figure out where the boundaries are. That can be fine, unless you really need the features for the effects you want. It's often best to keep it in mind and not go way off into the weeds by using expensive things excessively when that will be hard to fix later, but at the same time don't optimize prematurely and save performance that you could have used or, more likely, waste lots of time saving performance when there is plenty.

Skeletal animation doesn't lend itself well to a large number of particles. A particle system is highly optimized for a very specific task. You can use a bone or point attachment and render particles at runtime between your skeleton layers using a real particle system, if that is really needed.

You can do particles in Spine, but you'll want to keep it simple most of the time. Sometimes you can use a single image with multiple particles on it and animate in a way that it is hard to tell they aren't separate.

At runtime you can pose a skeleton once, then render it multiple times, possibly rotating it each time. This can cut out a large amount of effort to pose the skeleton, if the duplication is acceptable or can be hidden.