What you did wasn't so much a bad design, because you considered real-world things like troubleshooting, minimizing equipment failure impact, etc.
One possible issue with spanning VLANs across devices, you can get into some interesting "corner cases", like unicast flooding.
But generally, avoiding spanning VLANs across devices, is much the same thinking as possibly your primary reason for using two stacks of 4, "Don’t put all your eggs in one basket ".
Before L3 switches, when L2 switching was much, much faster than L3 routing, we had the saying "switch when you can, route when you must". I.e. we wanted to avoid L3, if possible. But with L3 switches, where usually L3 routing is just as fast as L2 switching, we can avoid many potential L2 issues by using L3.
So, again, your reasons for splitting the 8 edge devices across two stacks, is reasonable. Often people can be very nervous with large member stacks, often citing slow CLI response, or some occasionally will say the larger member stacks just appear to have more issues.
Even assuming all those potential issues are true, for just two stacks, that are L3 capable, what's the real benefit of using the dual 9300X between just two stacks? Any data that goes between them flows up and down their links to the 9300X, but if, instead, they just link to each other, the two stacks, isn't that pretty much the same?
If you had more than 2 stacks, then a core/hub would make much more sense, but again, for just two stacks, is the 9300X really a good benefit? (Besides avoiding the purchase of pair of 9300Xs, you would cut in half the number of 10g transceivers.)
If the above risk of large member stacks is over stated, and we run just one stack of 8 members, besides, possibly more so, no benefit to having the 9300X, we eliminate most of the NM transceivers, the NMs themselves, and increase the bandwidth between the 2 sets of 4 members, because now all 8 share the same StackWise 160 gig ring.
So possibly, you might have been fine using a 1-tier design, i.e. just a single stack of 8 9200s.
Should you have done that? I cannot say. I don't have all the information you did/do, and even if I did, I might do it differently, because I weigh the same facts perhaps differently. It's not always a choice of right or wrong, good or bad, but sometimes of taste. Perhaps you like vanilla ice cream and I like a different flavor; is flavor choice right/wrong, good/bad? However, the temperature to store ice cream at, that's not so much a matter of taste, laugh, unless your "taste" likes brick hard ice cream or liquid ice cream.
Laugh, to your earlier comment, there's no straight answer, there is, it's "it depends".
For example, two different branch sites requiring the same number of like edge ports, but what those ports are being used for, can very much impact how much effort/expense is committed to trying to avoid some network issue.
So to recap, the only "bad" thing you might have done, or the most questionable, was having the same VLANs across both switches. Yea, totally understand, not wanting one stack taking down the whole network (although if the dual 9300X stack is the one that hiccups, is that really much better?), but a multi floor single VLAN network could be split into two single floor VLANs, and those replacement VLANs, one per switch. (Yea, I also appreciate the latter is a more work, and don't know how tight you're on address space, nor ratio of DHCP hosts to static IPed hosts, etc. Just, there's often many alternatives.)
(BTW, something I like to do, on chassis line cards or stacks, allocate ports, for the same VLAN, vertically so that if one line card, or one stack member fails, rather than possibly taking out a whole VLAN, it takes out a fraction of multiple VLANs. Whether that alone is a plus or a minus, is hard to say. However, if you can have one more stack member, than you actually need, if need be, you can rapidly re-patch one member's ports to the hot spare. But even without a dedicated spare member, you might re-patch to another member whose port is inactive. The advantage of the vertical allocations, port # is the same VLAN on all switches; you don't need to look at configs. [Logically you can do the same with line cards, but often you don't have as many, and usually you can easily pop them in and out while chassis is running. Replacing a switch member is a bit more involved, and that's does seem to be the kind of thing that can cause a whole stack issue.])
