Unity does have some weird rules to obey if you want dynamic batching to work.
I don't know enough about TK2D to tell what part of it might be breaking batching, but your setup does sound ok.
I think it does boil down to you having four materials/four sprite collections. Unless TK2D has some sorcery behind it that allows this to be batched, it seems like it inherently can't be batched.
The "scaling problem" seems like a separate issue.
Skeleton JSONs aren't supposed to care what resolution the atlases are. It should just work as long as the atlas data correctly describes how the images were scaled (I think?). But I have seen UV-mapping and FFD stuff break before from scaling, not sure if it was on the skeleton side or the atlas side.
But I think that was fixed at some point, and then broke again at some point then got fixed again. I'm not sure where it is now.
But the ideal is that you can export a json, then swap around different resolution atlases and it should work just fine. I actually tried this before and it worked. Again, I'm not sure how the atlasing works on the TK2D side so whatever adjustments have to be made are probably related to how the TK2D atlasing/runtime works.
Kinda unrelated info that might be helpful:
Scaling the Transforms of GameObjects was definitely was an issue, but they made uniform scaling of SpriteRenderers not break batching. They hinted at doing the same for MeshRenderers (which Spine-Unity relies on) but I actually don't know if they've managed to do that already.
Scaling the assets should have no effect on batching though. That's an import operation and not something that's calculated at runtime. Batching will break if you're pulling from different textures.
Additive blending thankfully doesn't break batching with Spine-Unity as long as you're using the Spine\Skeleton
shader or any premultiplied alpha shader.