Unfortunately, something is wrong with the object file, and it is symmetry and UV-map related. (exact reason still unclear)
When I test with a rebuild object flie all is good. To be continued.

Just adding a useless two-coppers to the conversation... :)
It may be how the subdividing routine determines how the vertices are ordered and adjacency. I have no idea at all how the subd routine works in the newer versions of Poser nor what they're based on nor what type of subdivision operation they perform. (I use Poser Pro 2012. Yes, I'm three years behind everyone else... which is where I normally am. Going to vote for Mondale in the next election, too, 'cause... Why not? :) )

But, apparently, adjacency is critical in subd routines in something like OpenGL: https://www.cs.cmu.edu/afs/cs/academic/class/15462-s13/www/lec_slides/project2_slides.pdf That may hold true for what's being used in those nice new versions of Poser.

But, some modeling applications have weird issues with vertice orders and mirroring surfaces and such. Now, that doesn't mean they're doing anything wrong, it just means that if something is critically dependent upon them, things might get a bit wonky. (Not much usually reaches that deep into specifics in Poser. Morphs do, however, for example. And, there's a morph issue here, as well, right?) Normally, OpenGL uses vertice order to determine simple stuffs, like face normals, and we can easily see that effect inside the Pose Room. But, let's say that mirroring the object in the program used to create it inverts the order on one axis when it creates a mirror. Welding it to an existing mesh will change the face normals, by simple .obj conventions and, for display purposes, that's not an issue. It looks just fine in the Pose Room and there's nothing much that anyone would normally see in most uses of the object. Normally, when rendered and even for dynamics, that's not an issue, either. (Since, it appears by the above description that the dynamics engine builds it's own deformer cage and performs the operations on it.) But, let's say the subd routine is looking for that specific information for something like calculating adjacency in its subdivision routine. It would do fine when working with everything BUT the vertices on the border of the two "halves." In that region, it couldn't figure out which way was up... or sideways, if it was dependent upon that very detailed, very specific vertice information in the original mesh.

Or, let's say it's using the UV coordinates in a weird way. (I shudder to think why, but I guess it's possible. Doesn't make any sense, though...) We know that, at least in the past, Poser did funky things with the border regions of materials with shaders dependent upon UV values and such, right? (I think.)

I profess to know nothing (This keeps me generally content and happy in real life... ) and I don't have a version of Poser that does subd on the fly like you guys. But, I'd be happy to take a look at a simple object file in order to see if I, in my limited experience and capabilities, could figure something out.