Managing the performance of your game with multiple atlases and parts in Unity depends on several factors, including the total memory usage, the number of draw calls, and how you manage the loading and unloading of these assets. Having separate atlases for Hair, Body, Hands, Feet, Eyes, Mouth, Ear, Nose, Weapon, Backpack, FacialHair, Masks, and other parts is common in games that feature high levels of customization. The key is to optimize how these assets are used and loaded during the game.

For Unity, using multiple atlases can be efficient if managed correctly. Unity's ability to batch draw calls means that having multiple atlases won't inherently cause performance issues, as long as the number of draw calls is kept reasonable. The Spine-Unity runtime also provides tools for dynamically repacking textures at runtime to reduce draw calls, which can be beneficial for games with many customizable parts.

Regarding the parts themselves, having many separate pieces for customization is a common approach. The performance impact will depend on how these parts are managed, the complexity of each part, and the overall number of vertices and bones being animated. Unity and Spine are both capable of handling a significant number of parts and atlases, but optimization techniques such as atlasing, mesh and bone reduction, and efficient asset loading and unloading should be considered to maintain performance, especially on lower-end devices.

The fact that the images are not trimmed and retain their original bounding boxes can increase the memory footprint of your atlases. While this approach facilitates swapping parts with different sizes, it may lead to less efficient use of texture space and potentially higher memory usage. Consider using polygonal packing in Spine to reduce atlas size or dynamically loading only the necessary textures for the current scene or character configuration to optimize performance.

In summary, while having multiple atlases and parts is common in customizable character systems and does not inherently lead to performance issues, careful management and optimization of these assets are crucial to ensure good performance across all devices.

Spinebot gave good info. See also:
https://esotericsoftware.com/spine-metrics#Performance
In a nutshell: avoid deform keys unless you really need it, prune your meshes as much as possible, minimize use of clipping, if you must use it keep the number of clipping vertices at 3 and clip as few attachment triangles as possible, and the number of vertex transforms is an indicator of the amount of work that needs to be done.

Swapping out atlas images is a traditional technique but is not typically how it's done with Spine. Swapping means each atlas region is as large as the largest region that will be swapped. That can waste a lot of atlas space, similar to packing a grid of frames for frame-by-frame animation.

With Spine there are many options. You can pack polygons tightly. Atlases can have multiple pages. You can provide multiple atlases with regions in different places because the regions are found by name, not by location in the atlas page. You could use multiple atlases pages, sorted to minimize draw calls, or using various techniques for drawing from multiple textures with a single draw call. Or you could pack an atlas at runtime based on the actual regions needed.

What you choose depends on what you really need. If you don't need to scale up to thousands of regions, there's no need to put in the effort for a solution that can handle that. A whole lot can be packed into a 4096x4096 texture, 1-2 are enough for most apps. Otherwise you would choose the next simplest solution that meets your needs.