I think the approach you are probably looking for is to trigger damage based on some event, which is keyed to a particular time or frame in the animation. I'm not sure exactly how you can set this up in your case as I'm not familiar with the specific tools etc. but the general concept would be:
- For each attack animation, define at which frame / time offset the damage is applied.
- Watch for this event happening in code, or check each frame after starting the animation to test if the specified time has past.
- When the event is triggered or the time past you can then apply the damage. At this point you should know everything you need to such as: The unit attacking (hence it's damage and stats), the unit being attacked (hence the appropriate target and it's defenses etc) so you can apply the damage appropriately.
Some advantages of an approach like this are:
You can pick the damage event time to coincide with the the sword swing, or the muzzle flash etc. This signifies the "active" or "hit" portion of the animation so you can tweak it to make it look right. Potentially you can also manage DoT attacks, or attacks which persist for multiple frames in a similar way by recording a time period that the attack is active, though you then need more complex code to handle how multiple hits to the same unit are processed.
It's a fairly light system and should not need much overhead (in code or cycles). If your units are already capable of attacking each other then you already have all the targeting information, and presumably the damage calculation setup. All you need to incorporate is the timing aspect, which should be driven from the animation.
It's data driven (either via the animation, or easy to make so via your game files), so should be easy to tweak / change over time as you iterate on your units. This also helps for modding etc.
Having written a hitbox system myself from scratch, I'd say that it's almost certainly overkill for a game like you have described, certainly as a first iteration. There is a lot more overhead in terms of code (and performance) to manage life-cycle of hit/hurtboxes and checking for their intersections.
They do give good results, and can be fairly straightforwards if you limit the hitbox shapes permitted to rectangles, but I'd start simple and work up as you need it.