You probably know that a correct answer is x=4,y=3,z=5.
Here is how the result of isolve may be explained (which does not make it correct!):
xpr:=(1 + 1/x)*(1 + 1/y)*(1 + 1/z);
(x + 1) (z + 1)
2 x z
z + 1
-1 + 3 z
and isolve will merrily solve this by z=-1 which gives x=0. All perfectly reasonable, right? Except that we make an implicit assumption of x>0 as else the given solution of xpr2=2 for x is not bounded. But just looking at the solution for xpr2=2 this little detail is lost. On the other hand; there is nothing wrong with xpr2 a priori either.
So the message here is that one needs to keep track of assumptions, in particular the implicit ones. Note that in many cases what I outlined here would be a perfectly fine thing to do; as long as all intermediate results are well defined.
I am not sure this qualifies as a bug. I would call it a limitation (of isolve). Such limitations are frequently encountered with any CAS, not just Maple.