The real simple reason is that the programmers are convinced that TRUE Unimesh will solve all the problems.  The problem of course is that there is no defined outcome that Unimesh is suppose to be.  The basic one (which several scripts have been created take care of) is being able to Export an Object file and be able to use it in a modeling program and bring it back in as a FBM.  They work great in Poser BUT for some reason DON'T seem to work in other programs, or at least that is the excuse that I have heard. 

The problem is that the Unimesh the programmers are trying for will get rid of the splitting of the figure and only work with it as a single mesh.  Ignore the fact that Poser has worked with split Mesh for the last 25 years.  Also that a great amount of content is only in split format (as the original object files are long gone) so the problem is how to recombine all those split scenes and make it so that it will work in other programs (for what reason unknown).

The simple solution is to load the object as it is now doing, HOWEVER, Keep a copy of the original obj and also split as it currently does.  It would be a piece of cake to create a cross reference table that tracks each vertex so that when a vertex is moved in the split object it is updated in the solid object and visa a versa.  And when it comes time to export (or save) use the solid object.  Since the solid object has not changed order or number of vertices it remains exactly like the original with just the vertex's moved in space.  That way very little has to be done to the program and those functions that work best with split mesh can work with that and those that like solid use those.  About the only thing that wil take a bit of change is rendering when part of the model is removed (such as the forearm).  

Poser 5, 6, 7, 8, Poser Pro 9 (2012), 10 (2014), 11, 12, 13