Few key things you need to understand:
(1) Realtime 3D animation (as opposed to prerendered 3D animation) doesn't have an actual "framerate". Everything is interpolated in conceptually continuous time— sliced arbitrarily by the update rate of the engine; The framerate you see is however quickly your computer can update. For the average computer-user, and at reasonable detail levels, that's actually around 60fps.
Spine rests on a similar paradigm and, in game engines, piggybacks on the same systems.
(2) The "framerate" you see is only as a user of Spine editor. The timeline has lines, numbers and snapping so it feels like you're animating at 30fps. 30 is currently locked as the one-second mark. In fact, it should probably say "1 second" and not 30, because when it's saved, the keyframe time values as saved as seconds and not frames.
But, you're right. There is such a thing as stepped. And no, that probably wouldn't be the best way to go about it.
(3) I wholeheartedly agree that professional animators trained "classically" and who work with the limitations of 8fps/12fps/24fps need to be able to work with Spine comfortably. A custom framerate purely on the timeline (being able to set frame 12 or frame 24 or frame 60 as the 1-second mark) was removed from the list of planned features many many months ago. I'm still not sure why.
Regardless of this, the keyframes will still be saved in terms of seconds, and without the proper code on the runtime side, the framerate will still play at the full capability of whatever machine, system or engine it's running on. It could be 30fps. It could be 144fps.
(4) To achieve discrete-framed animations, the runtime code can be easily modified, given that your engine also allows you access to observable time and manageable variables (or at least allows you to manage your own).
The Spine runtimes are already set up to receive customized update time deltas.
Limiting the framerate amounts to just delaying animation updates until enough time has passed (eg, 1/24 of a second, or 1/12 of a second).
And achieving discrete and predictable 12 and 24 fps poses (like you would expect in hand-drawn or pre-rendered animations) amounts to restricting the time values being passed into Spine's runtime code in discrete 1/12 or 1/24 chunks.
(5) Therefore:
On the editor side. It's a pain to animate "classically". You can't snap the keys in the correct times. And you can't preview it at the correct frame rate.
On the runtime side, because the source is editable by the game developer depending on the game's needs, you can make animations play at 12 and 24 fps. In fact, the same frame-limiting code can be used to improve performance if Spine animations are bottlenecking the performance such as when there are too many instances updating at once.
Yes, I agree that the editor feature of changing the framerate on the timeline (which affects snapping) is very useful. I think the feature makes sense, whether for animating things to have a traditional feel, or translating or combining frame-by-frame animated things with interpolated ones or achieving better pose-accuracy at high framerates, it's very, very useful.
I've been barking at this tree for a long time. And I appreciate it when people express their use cases for this.
