Ofcourse it's easiest to do everything on one machine in one process, preferably on one thread.
If you have the resources: CPU cycles, memory, bandwidth, datatraffic and your players would accept the lag, why not?

Streaming games is the next big thing, next to this 'cloud' thing they keep talking about.
Which begs the answer to your "Why not?" question.
I would like to say that I can't really use it and just like 30 years ago it is a fad waiting to be broken, but I would be wrong.
It could be that this image download architecture is going to stay and am sticking myself into the wrong hole with the wrong philosophy like the RMI thread person.
I think the broken part is that we could see a move to much larger requirements on the client to the point that you can't just stream images again at 60 fps. Like higher resolutions. Well I can only hope. What do you think the likely hood of the requirements scaling up so much that bandwidth is an issue again?
I think that some low latency games will still be much better without the download image architecture. I notice the lag, but for many games it is fine. VNC did the same thing 30 years ago, but now all of the sudden it's a big deal.
Like I said before my future project may depend on low bandwidth and ad hoc network requirements so I probably can't even use it for my games unless I want to have 2 different network philosophies.
I am at a point where I will probably have 4 3D renderer implementations under my AllBinary Platform and now possibly 2 network architectures. It could be more than I could handle.
Short Answer:
I would say that the simple way is going to be far better, but sadly my direction will keep that from doing it unless I decide to have 2 different network architectures to work with. Looks like I will need to make a real decision. f**k.