I'm working on a very different project, but with similar desires: A reasonably intuitive way to overlay larger hex grids over smaller hex grids such that the alignment isn't too complicated.
One feature I'm requiring in mine is for the larger hexes to be required to be at the same angle as the smaller hexes, which means that if I were to use the right-hand option you provided, I would be required to iterate that twice before getting an acceptable grid. (Since your right-hand subdivision rotates the hexes by 30 deg, performing the subdivision twice rotates a total of 60 deg, resulting in the same alignment as the original.)
So that's one pro-con you can weigh: Do the original hexes align in angle with the subdivided hexes? Users may get confused if every time they zoom in, the cardinal directions shift from N/S, ENE/WSW, WNW/ESE to E/W, NNE/SSW, SSE/NNW. If you intend your game to have keyboard controls for accessibility, this is particularly relevant, as the keyboard layout would have to alternate between two different interpretations, confusing both to program and to use as a player.
It seems that one implicit rule you're using is, for every hex in the original grid, one hex in the subdivision must have the same center. This makes sense when the thing the viewer is focusing on are the areas of the hexes. However, in my project, the viewer is focusing on the edges, the boundaries, so I am instead trying to optimize for subdivisions that share as much edge length as possible. If you're using the hexes to model things in your game such as political boundaries, you may similarly prioritize sharing edges between zoom levels.
There's two ways you can describe the subdivision I show in the figure below.
Every white hex is subdivided into three and three-thirds hexes. (Scale factor is 1/2, so each hex has 1/4 the area.) Three vertices each get a 1/2-size hex aligned with both edges, while the alternate three vertices each get a 1/2-size hex centered on the old vertex.
Every white hex is subdivided into kites in the standard way. Then three kites are subdivided into three pieces to be shared with neighboring kites to reform hexagons.
I mention the kite subdivision because it (or the triangular grid it reveals) may help you realize other kinds of subdivisions convenient for whatever you're doing. (After all, the triangular grid is the dual of the hex grid, exchanging vertices for faces, so each implies the other.) It's also plausible that showing the kite (or triangular) grid while zooming occurs may help users understand how the subdivision is occurring. (That's true for your subdivisions as well: The left-hand one could display the standard subdivision of each hex into 6 equilateral triangles, while the right-hand one could display the kite subdivision I used.)
For your two area-focused subdivisions, zooming with just the basic lines is likely already too noisy. In that case, you could instead remove the line display and show center dots of all the hexes while zooming. That way, it would very simply illustrate the part that is preserved from zoom level to zoom level, and give an intuition for how detailed the map currently is.
