Some notes:
1) Make sure all divisions capable of dividing by zero at runtime are protected against. For example, right now, the direction.Normalize will produce a NaN-filled vector if mType.compactCollider.Position and new_pos are the same. This could be what you're seeing.
2) The orientation matrix's forward vector is already unit length thanks to the properties of a rotation matrix, so normalizing it has no effect.
3) The cylinders are kinematic since they were created without specifying a mass. The motors won't be used, since kinematic objects have effectively infinite mass and can't be moved by forces. The EntityMover/EntityRotator will control the velocities directly instead.
4) Even if the objects were dynamic, you don't have to create your own motors to pass into the constructors. That constructor overload is simply there if you already have a motor sitting around available for use. I would recommend just using the simpler entity-only constructor of the EntityMover/EntityRotator. This would avoid the other boilerplate, like setting IsActive to true.
I also would like to know if there is another method for "waiting" for the monster to rotate and move before moving to the next line of code without using timers or anything too complex (this code is run quite frequently for many...many entities).
There are a few options here, but none of them have any engine-level convenience functions:
1) If a completely arbitrary dynamic simulation is involved, the only way to know when a goal is met is by polling, because there is no closed form expression for when the simulation will finish in general. Polling is not as horrible as it might seem, even if you have 1000 entities and you're polling every frame. Consider that the engine is doing orders of magnitude more work on every single individual entity. Provided that the polling process isn't abnormal/crazy expensive, it will likely be irrelevant to the running time.
2) If the simulation is constrained in some way, those constraints might make it possible to predict particular time of completion. For example, if you want to know when the EntityMover is going to succeed in reaching its goal when operating on a kinematic entity, the answer is always 'at the end of the next update' because it sets the velocity to exactly the values required to hit the goal, and no dynamic interference will stop it from reaching the goal because it has effectively infinite mass.
If you can point me to a specific example in the docs as well that would be most appreciated. I can't seem to find anything on Movers and/or Rotators as yet.
EntityMovers and EntityRotators don't have any dedicated documentation since they're a very thin convenience layer around just setting velocities or using motors. There are some examples of their usage in the BEPUphysicsDemos, though. For example, the In the CharacterPlayergroundDemo, they move the platforms around, and in the PathFollowingDemo, they move the... flying block thing.