Well it’s actually an easy answer
In-Place (coders love it animators hate it)
In-place animation is reactive meaning that to trigger a state it needs a component to react to. Think of it as a puppet in a box and to drive the animation in most cases uses the movement component of the character BP which is actually what moves relative to the bounding box. For example you push traditionally W to move forward the capsule moves forward and the animation BP general casts for the movement state and triggers the corresponding animation take.
Since the animation reacts to the movement component all network requirements is handled by this component as to the important stuff like movement, error correction and top of the list replication and does so in an efficient manner. The important stuff gets transmitted and the clients only need to react to the state change on the local level.
Since the animations are reactive there is always a degree of latency as to when the animation has to blend into and out of a state change. It’s not noticeable at first but the more complex the animation the more lagged the animation feels
Since the animation is bound to the movement component it’s difficult to keep the player grounded, 3rd person, as they are bound to the bounding box at a constant velocity.
Root Motion (coder hate it animators love it)
Root Motion is event driven so is not limited by the requirements of a movement component. In-place animation has history of always working were root motion is the future and is the way all animations are done in media that is not a video game but at the moment lacks any kind of extensive knowledge base as to usability
Root Motion as a data set can control all movement requirements with in the animations which in turn can be evaluated, calculated, and state changes determined “before” the event is triggered. For example distance travelled with in the cycle can be calculated and direction changes made with out the need for a state machine and base the animation, as an example. on motion matching
As you can see a line is projected as to where the character is going and where it has been.
Another problem solver is since the animation movement is based on the movement of the root the animation is referenced to ground and not world space as being glued to the movement component so no latency issues or feet sliding
More or less there lacks a knowledge base as to practical application. Tutorials that make use of -in-place do not translate well when the use of RM is desired instead.
No component for network requirements and difficult to replicate.
If your game does not require network connectivity Root Motion is the future of animation sub-systems as it has a much more direct plug-n-play ability and is a more logical choice for data driven animation requirements. You can for example already purchase a motion matching system
In-place is more or less a must as although you could benefit by the use of RM as a data set the complexity of on-line gaming needs the trusted features of the movement component.Clients could miss the stop event an the player will continue to move forward as a fire and forget missile