If you have access to the original images, you should be able to pack them according to your needs.

see this page: Texture Packing - Spine User Guide
Particularly the section on Folder structure: Texture Packing - Spine User Guide: Folder structure

If you don't have the original images, you can still run Spine's Texture Unpacker.
But if the atlas had premultiply alpha applied, you'll have to be careful not to apply premultiply alpha a second time when you pack it again.

The way to not have those materials and underlying textures load at loadtime is to not have those attachment objects in the skeleton data at all.
But if they were to be loaded at load time, I think you can force Unity to unload the materials and textures that you aren't using.

At load time, all renderable attachment objects in all skins are given a reference to the material needed to render them, defined by the atlas region name that was specified in Spine (if no atlas region name was given, the name of the attachment is used as the atlas region name).
Atlases can't really be "swapped" at runtime. Each attachment stores the information needed to render it and they are shared across all instances of that skeleton.

MixAndMatch works by cloning those attachments so they can be modified without affecting other instances.
So you could technically create a skeleton instance, clone its attachments, then reassign their texture and material source based on a different atlas.
That's essentially still Mix and Match and still uses the same spine-unity AttachmentTools.
The MixAndMatch.cs example is only a sample of how Spine.Unity.Modules.AttachmentTools can be used. There are other ways to Mix and Match by cloning and manipulating skins and attachments.
But it's unclear what specifically to recommend since we don't know how "wrong" your skeleton was set up.

AttachmentLoader is the part of the API that allows customizing what an Attachment uses for rendering. See the docs here:
Loading Skeleton Data - Spine Runtimes Guide: AttachmentLoader

Most often AtlasAttachmentLoader is used, but you could write your own so the attachments are loaded without needing any texture atlases to be loaded (eg see RegionlessAttachmentLoader in spine-unity). Later you can assign the necessary data so attachments can be rendered. Note that exactly what is needed to render depends on the renderer. If you don't want to customize the renderer, you probably want to provide the same data that AtlasAttachmentLoader provides.

One use case for this is to have thousands of attachments where it isn't feasible to load all the atlas pages at once. First you'd load all the attachments without atlas regions. Later, when you know the subset of attachments that will be needed on-screen (eg for a specific level, for the gear a character currently has equipped, etc), then you would load only the textures necessary and configure only those attachments. It could be that you have individual attachment images and you pack an atlas at runtime specifically for the attachments you need. Or maybe you are choosing to load just one of a number of atlases because they can't all fit in memory at once.