We have started a basic prototype to test our desgined combat system. The game is a 3D isometric RPG developed with Godot 4, and my first proposal was to add a collision box to weapons to detect when enemies were hit. It sorts of works, but I delegated the work on the second programmer and he proposed to discard collisions as primary way and simply use a backend to determine what targets were in range and inflict damage to them. That was my idea, years ago, but right now I think the collision way is better, specially after finding some Godot limitations related to determining animation state when using an AnimationTree. Is there any other approach for this, or should I enforce the collision based solution?

I think that both approaches have their advantages and disadvantages, and that, more to the point, which is better for your combat mechanics depends on those mechanics, as well as how you intend to use the tools in question.

You say that you're making a 3D isometric RPG. I gather, then, that you're likely to have a relatively-distant player-perspective, and I'm guessing, at least, that you're unlikely to intend that collisions determine anything as fine-grained as which body-parts are hit.

So, in that case, I would imagine that aside from the specifics of your collision engine and whatever tools your programmer intends to use for their implementation, there's likely to be little between the two approaches.

Speaking in generalities, I would expect your programmer's approach to be simpler and more reliable, and your approach to be more-easily flexible.

rogerdv said:
add a collision box to weapons to detect when enemies were hit.

Why not the other way round? Express the rules as abstract tables and formulas giving the chance of different results for various combinations of attacker, defender, weapon etc. and then, after deciding the attack result, adjust the animation of the weapon swing to show the various types of hit, miss, critical hit, fumble and the like.