Foreword
Yes, I'm aware that this question is 9 months old, and I assume that the OP has either figured out the problem or moved on, but since I was having the exact same problem and I was finally able to come up with a solution (through a lot of struggle) , I'm going to post an answer for future reference. I had better luck understanding the problem with the provided .blend file than my own, so I'm grateful to the OP for providing it.
Note, I am also a beginner with animation nodes and blender animation in general, so keep that in mind. I have provided an updated .blend file, a modification of the original here: 
In particular, reference scene "node_tree_vt_4" for my final solution. I'll also provide some screen shots.
Analysis
This problem really has nothing to do with animation nodes: it's a problem that you would still have if you were manually trying to duplicate a full mesh-rig improperly as well. Although it's not technically an AN problem, I did implement the solution with animation nodes, and indeed you're more likely to experience it when duplicating with AN.
Basically, the problem being made is you're only instancing the mesh, not the rig as well. Normally, when you manually copy a rigged object, you box select the object or select "select hierarchy" from the scene collection, so you naturally select the mesh and the rig so you don't have this problem. However, when you use AN node "Object Instancer" on the target object, it will only duplicate the mesh. And that object, will have an armature associated via a modifier (this was a key thing for me to understand). Here is an example of the armature for the clive base object:
Note that when you instance the base clive object with AN, it will create "clive.001", "clive.002" etc., but if you look at their linked armature you'll see they're still referencing 'clive.rig' which is still located at 0, 0, 0 and that's why they're skewed: they're attached to an armature at the origin, not where they are located.
To fix the problem you have to instantiate and move the base rig as well.
So here's a couple of screen shots. Note how in the following "clive.002" is properly associated with "clive.rig.002" and how none of the objects are skewed. In the following "1" is where we created the meshes, "2" is where we create the armatures/rigs, "3" is where we loop over the meshes and rigs and assign the proper rig to the mesh, and "4" is where we do the animation:
Here is a closeup of the new part of the AN in case the first is hard to see:
Final Thoughts
Performance appears to be a potential problem. With 4 armatures I'm getting about 1.6 ms per animation frame, and with 10 armatures I'm up to 10 ms. To get 30 fps you're updates have to be less than about 30 ms. Typical AN updates times are on the order of .07 seconds, so it's takes quite a bit of overhead to do it using AN. This might be where I don't know enough about AN: in one of my attempts I was getting 340ms until I re-implemented it in "node_tree_vt_4" and got it down to 1.6 ms. You may want to separate out the creation of the meshes and rigs from the animation step anyway, because you essentially only have to run the "create" step if you change your "n". However, even then, I'm not sure if you'll be able to get real-time animation if n=1000, for instance -- although you should still be able to bake it.
Also keep in mind that mixamo armatures can have their own coordinate system e.g. x and y are interchanged, and distances are in centimeters not meters, so on my own project if I want to move the armature 2m on x-axis, I actually have to move it 200 on the y-axis.
){kind=link}