If your not familiar with the basics of animation the difference between root motion and in-place can be confusing and more so when referencing tutorials based on in-place.
So in general all traditional animations is based on root motion as far as in world movement goes WITH the exception of video games where the player controls player movement with some form of controller.
In-Place animation.
In-Place animation is reactive in that it’s state change requirements are defined by the capsule, also referred to as the bounding box, so it’s this bounding box that is being animated as to real time and in world interaction. Climbing a ladder for example it’s the capsule that is climbing, with the assistance of the movement component, and it’s the MC that tells the the animation bp as to what the required state change is needed. In a manner you need to first produce the world interaction via the movement component as the controller and the pass the correct state change to the animation BP.
The good.
The MC does a lot of the network requirements as part of an online game such as replication, error correction, in world placement of the actor, and is key as to all in world interaction that saves a ton of work that would have to be replicated as to the demands of the network system.
Out of the box though the movement component is limited as to function as a “just make it work” with a very basic feature set necessary to get the player moving as a controller. Usually special requirements are handled in the animation BP by evaluation as say our example of a ladder climb. To the MC the player is “can fly” and it’s the Animation BP that determines that the player is “climbing ladder”
The Bad.
The movement components velocity is referenced to world space as a constant so the player models movement is more like a bullet being fired from a gun so creates issues for the in-place, reactive, behaviour of the character animations, such as gluing the feet to the ground preventing the player from skating.
Authoring animations for a video game has it own requirements as to correcting for movement issues generated by the MC that could be corrected by expanding the abilities of the MC as to data drive design.
Root Motion.
Root motion is event driven as all the animation requirements are built into the data set and it’s root motion that is used as to general animation requirements for such things as animated feature films. As a fidelity asset it’s the best as it places total control of movement behaviour in the hands of the animator as to authoring in a straight ahead manner through the use of the root bone located in a typical UE4 player model at 0 0 0. Once UE4 is told that the animation is RM the location of this bone is tracked by UE4 and when a state change is required it starts at the current location in world space.
The good
The authored animations is an absolute as being referenced to ground which is typical in all things involving animations with the exception of a video game. Since the require data is contained with in the data set makes the animation BP data driven as to any kind controller you wish to plug into it from keyboard and mouse to VR type controllers as the controller only needs to send the required trigger. Another advantage is since critical data is available, with out the need of the movement component, distance travelled can be calculated as to when and where the player will intersect a world object and determine before hand the correct state change. Say your player is jumping off a roof Borne style through an open window it can be determined before hand if it makes it or not. 
Another example is movement matching but a different topic.
The bad
With out the movement component network requirements becomes difficult as what the net code does is still a mystery in all game engines as to what it actually does. Yes you can replicate the event trigger but net replication would require the replication of an event to be a constant as to when to start and when to stop for RM to be of any value over the in-place option.
How do you know you got it right.
When imported all animation is accepted as being in place unless with in UE4 you set the takes behaviour to “root motion”. This is the first indication that you at least got the animation right as the take will snap from moving in world to 0 0 0 local. The data is still there it’s just now referencing the location of the root. If you set the take to root and it sill moves in world space then the animations is probably using the hips, and not the true root, as the means of world movement as an offset.
In the animation bp you also have to tell UE4 that the animation being used is root motion as to the opinion setting that determines the behaviour. In this case a setting of “always use root motion” should do the job. To see if it “triggers” set up a spawn character and wire key pressed W into the run_forward , for example, and when you spawn pressing W off your player should go.
Sorry for being a bit long but I found understanding how and why it works gives a better understanding of why it’s not rather than trying to solve the problem in an open forum that may or may not work.