That's completely up to the devs.
You don't actually want your animators choosing export settings. That won't be consistent across Spine projects and future exports. Settings can easily be forgotten or misapplied. In situations like yours, packing may happen later, with more images. Someone might forget to update exports and then the project is out of sync and no one notices. All these and more problems!
The most professional setup is that animators do not perform exports. Instead, the app's build system should perform exports. That way the built software always has the latest exports that match the latest projects, and all exports use specific, correct settings. Not only that, but upgrading to a newer Spine version is easy: animators switch their editor to the new version, developers switch their runtime to the new version, and the build exports the Spine project files using the new version. Zero extra work!
If a client only receives exports, that will be a problem when they upgrade to a new Spine editor or runtime version. The Spine project is the source of truth, not the exports. To upgrade you need to re-export all your project files. If your build already does that, it's free! You just change the version number and you are done. Otherwise you have to re-export manually. That's fine for a couple projects, but for many you'll want to write a script (and then put it in your build!). However, if you don't have project files, you have to first import the data to generate a project file so you can then re-export. That is unnecessary pain, better to properly setup your asset pipeline from the start and have your software build perform the exports.
Your deliverable to clients should be 1) the Spine project file and 2) the unpacked image files. The client will need their own Spine license to perform exports, but they need that anyway to be able to legally distribute the Spine Runtimes.
