I have been looking at this interesting problem, and I think I have a possible answer. I believe the artefact is due to the 'winding order' of the vt entries within the face definitions.
I am aware that the winding order for vertices within the face definitions is used to calculate the face normals, and that is documented, but I have never come across definition for the winding order of VT's. Nevertheless Poser seems to be very sensitive to them.

An example:-

v -1.00000000 -1.00000000  1.00000000
v -1.00000000  1.00000000  1.00000000
v  1.00000000  1.00000000  1.00000000
v  1.00000000 -1.00000000  1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000  1.00000000 -1.00000000
v  1.00000000  1.00000000 -1.00000000
v  1.00000000 -1.00000000 -1.00000000
v -1.00000000 -1.00000000  0.00000000
v -1.00000000  1.00000000  0.00000000
v  1.00000000  1.00000000  0.00000000
v  1.00000000 -1.00000000  0.00000000

vt  0.11894488  0.04803747
vt  0.29814872  0.04803747
vt  0.29814872  0.18821995
vt  0.02934299  0.46858484
vt  0.02934299  0.18821995
vt  0.11894488  0.18821995
vt  0.29814872  0.46858484
vt  0.29814872  0.60876727
vt  0.11894488  0.60876727
vt  0.11894488  0.46858484
vt  0.38775063  0.18821995
vt  0.38775063  0.46858484
vt  0.40683913  0.57345837
vt  0.49905956  0.57345837
vt  0.40683913  0.84908801
vt  0.49905956  0.98690283
vt  0.49905956  0.84908801
vt  0.68350047  0.98690283
vt  0.77572089  0.84908801
vt  0.68350047  0.84908801
vt  0.68350047  0.57345837
vt  0.77572089  0.57345837
vt  0.68350047  0.43564355
vt  0.49905956  0.43564355

vn  0.57735026 -0.57735026  0.57735026
vn -0.57735026 -0.57735026  0.57735026
vn  0.57735026  0.57735026  0.57735026
vn -0.57735026  0.57735026  0.57735026
vn -0.57735026 -0.57735026 -0.57735026
vn -0.57735026  0.57735026 -0.57735026
vn -0.70710677  0.70710677  0.00000000
vn  0.70710677  0.70710677  0.00000000
vn  0.57735026  0.57735026 -0.57735026
vn  0.70710677 -0.70710677  0.00000000
vn  0.57735026 -0.57735026 -0.57735026
vn -0.70710677 -0.70710677  0.00000000

g cube1_default
usemtl default

f 1/6/2 9/1/12 12/2/10 4/3/1
f 2/10/4 10/4/7 9/5/12 1/6/2
f 3/7/3 11/8/8 10/9/7 2/10/4
f 4/3/1 12/11/10 11/12/8 3/7/3

f 5/13/5 9/14/12 10/17/7 6/15/6
f 6/16/6 10/17/7 11/20/8 7/18/9
f 7/19/9 11/20/8 12/21/10 8/22/11
f 8/23/11 12/21/10 9/14/12 5/24/5

The above will display as a hollow cube, each side of which consists of two faces. These will display artefacts as they were created from a box mapped cube. I deleted the ends to simplify.

If you replace the f lines with the following:-

f  1/1/2  9/2/12  12/3/10  4/4/1
f  2/5/4  10/6/7  9/7/12  1/8/2
f  3/9/3  11/10/8  10/11/7  2/12/4
f  4/13/1  12/14/10  11/15/8  3/16/3

f  5/17/5  9/7/12  10/6/7  6/18/6
f  6/19/6  10/11/7  11/10/8  7/20/9
f  7/21/9  11/15/8  12/14/10  8/22/11
f  8/23/11  12/3/10  9/2/12  5/24/5

Then the artefacts disappear. If you study the two sets of face definitions, the ony difference is the order in which the vt references appear. Please not that the 'corrected' cube has distorted texture map. this is because I didn't change the actual VT entries themselves, just the order of references to them.

I welcome any thoughts on this. If this is the answer I hope somebody could write a little code to 'repair' .obj files.

Cheers

Ian