For my game (which, again, heavily inspired by DMC and other cuhrayzee games), I use my anim State Machine to control “player states”, not just poses.
Almost every anim state itself uses transition Notifies (upon leaving, entering, or moving between states) to set flags and trigger changes to the Character BP.
Thus if my character enters the “Dodge” state, it flips flags which disable movement control. If he enters the “Melee Ground” state, it flips flags which cease parsing stick inputs to capsule movement and instead queue up rotation interpolations for attacks. Etc.
So I use the pose states as “character states”; if a player is in the dodge pose, or the grind pose, or the shoot pose, and/ or their corresponding networks of sub-poses (reloading, dequipping, whatever), that information is relayed BACK to the character blueprint.
My AnimBP probably handles as much direct character control as my main BP. That seems appropriate for a DMC-type game, though, since animation is non-reactive. In shooters (the kind of game UE was originally built to handle and which many of its paradigms assume), animation reacts to player movement. Whatever the player does, the animation attempts to respond. Combat games are different; frame-canceling rules get complex, and what the animation is doing DICTATES what the player can he do (he cannot run mid-swing, he cannot dodge while in a hitstun anim, he cannot block while moving, whatever).
Personally, I say embrace it. Don’t get hung up on wanting State Machine access from the player BP since that’s where player movement is “supposed” to be controlled. Don’t be afraid to use InputActions to do nothing more than casting to the AnimBP to drive custom events (such as having the attack key do nothing in the player BP except tell the AnimBP to handle the incoming execution) or placing lots of logic inside the AnimBP or Notifies and Notify States.