At the lowest level I'd expect a simple Texture or TextureSlice concept (which may be an object, or a simple struct, or even just some conceptual data that's implicit in a set of separate arrays... don't try to shove conceptual thing into a distinct object, that's an abuse of oop).

TileSets would be a collection of texture slices with additional data, e.g. possibly collision data and tiling data. They would allow mapping a tile id efficiently to a texture slice. They might also contain some simple animation data.

Sprites are indeed better broken into sprites and frames conceptually. A sprite is the metadata that determines the frames, and possibly multiple tracks of frames (because you might have more than one animation). Or you might have each sprite be a single animation (or unanimated) and have a separate higher-level animated sprite controller that swaps between sprites for different animations.

I highly recommend the distinct sprite frame though as each frame of an animation has a lot of potentially different data. The sprite might be different visual sizes. It might have different hit boxes for physics. It might have different attachment points for setting items/equipment or spawning effects.

Regarding the origin, I generally also make that data (usually from a corner, since it's more accurate than "center" given that your sprites can have both odd and even dimensions). Some sprites or individual frames may want the origin to be the middle-bottom (under the feet), some the bottom-left corner, some the upper-right corner, etc. Define the "true" origin as a corner (usually the bottom- or top-left) and then provide an offset data with each sprite/frame.

And again, don't think of these as objects. Instead of a Sprite having an array of SpriteFrames, maybe the Sprite just has an array of texture slices, an array of origin offsets, an array of hitboxes, etc. A conceptual SpriteFrame without actually having a new object/class. This is especially useful for languages like Java where each object has an unreasonable amount of overhead due to every object being heap-allocated (C# does too if you use 'class' but not if you use 'struct', while C++ gives you total control).

What would a texture slice be composed of? My gut says it would be the data I push to the VBO for a sprite and all its frames

The minimum data really is just a rectangular region of a texture.

struct TexSlice {
  GpuTextureId texture;
  Rectangle dimensions;
};

That's it. A slice does not have multiple frames because a texture slice is not itself an animation. A slice may or may not correspond to a frame of an animation. You can reuse the texture slice concept to represent glyphs in a bitmap font, individual icons in a UI asset, frames of sprite animations, and so on.

I wouldn't write all that code to calculate texture offsets, either. That intimately binds your art assets to your code. Artists are not going to be rewriting a bunch of math every time they change something in a character animation. Let the artists specify where the frames of animation are in the source asset using a text file, or import the animation from one of the common sprite animation tools that are around these days. Make it all data driven.