Animations in which the character translates away from the origin are said to contain "Root Motion" - because the root bone moves.
This allows the animator to directly author subtle non-uniformities in the movement speed, in a "what you see is what you get" fashion. Say the character slows down slightly as their foot makes contact with the ground, then speeds back up as they push off again. Incorporating this via the movement script would be messy and error-prone.
By allowing this root motion to drive the movement of the game entity, we get a very close match between what the animator authored and what the player sees - minimizing mismatch errors like foot sliding.
But it can also make it more difficult to change and direct that motion at runtime. Your animations might cover a walk of 1.4 m/s and a run of 2.2 m/s, but if the player's input maps to a movement of 1.7 m/s the two might not blend cleanly to make this intermediate speed. Or if the only turning animations you have are 45 degree turns, then the player character ends up walking in a half-circle in order to turn around.
That makes root motion useful for naturalistic motion and performance capture, where you want all the little inconsistencies of a real creature's movements incorporated in the final result, and you're willing to sacrifice some amount of runtime control to make it happen. Cutscenes or special actions that happen with some fixed alignment (like interactions with cover) will often use this style extensively.
Animations where the character does not translate away are called "In-Place" - because the character stays in one place, like walking on a treadmill.
This makes it easier to blend and transition the animation with other animations the character can do, because they're all aligned at the same position/orientation.
The way the character moves through the scene is entirely up to the movement scripts, giving the programmer and game designer a lot of freedom to control the movement, pivoting to just the right angle or dialing the speed up and down. This can also make it easier to layer the animation with procedural motions like a jump that snaps to a target point, a rail/ledge to follow, or a moving object to ride.
The downside is that the scripted motion layered on top can look mechanical, and disconnected from the movement of the character's limbs. Seeing feet that appear to slide or swim across the ground, rather than making stationary contact and convincingly propelling the character, is a common artifact of this approach.
Some of this can be ameliorated by using IK (Inverse Kinematics) to nudge limbs to match their intended contact points. Or it might not be a big deal at all if you're animating something non-naturalistic, like a stylized cartoon character or a hovering sci-fi object or otherworldly alien creature. Or if your viewpoint is far enough away that those little misalignments don't really show, like in a city builder/god game/RTS.
So both approaches have their benefits and drawbacks, and as a result they're both used - often even in the same game, for different actions or at different stages of production.
Fortunately, Unity gives you powerful tools to decide how you want to use root motion, allowing you to use it to drive a body's movement through the scene, or bake it out if you want to work with it as an in-place animation. So you can change your mind easily as you iterate on your project and find what works best for getting you the results you need, and the way your team likes to work.