A component is used to give common behavior to different actors
you can parameterize that behavior using instance editable variables.
For example, in the component, you can make a boolean called “WillJump” and set it to instance editable. Then on a branch, if WillJump is true, the enemy will do jumping behavior.
Then if you have multiple different blueprint classes which implement this component, you can set the WillJump variable how you want for each one.
You can see this in action by looking at the character movement component which is attached to the character class. It has a bunch of different variables that you can set on every different class which uses the component.
Whether you separate a chunk of logic to a different component or not is a question of maintainability, organization, and optimization. A generic answer is not easy to give.
My best advice is to make as few separations as possible and only make a separation if there becomes a big problem which motivates you to do so.
Because the more you separate your code, the slower it becomes to work with.
This assumes you are working alone. If you are in a team, a lot more separation becomes mandatory, especially with blueprints.
But a good way to start would be just put all of the behavior into a component, and then if some chunk of logic is growing so large that you feel it will be easier to maintain by splitting it into its own component, then you can cut that out and transplant it.