I don't know exactly how Ghost handles restores - whether it is relatively sequential or whether it restores on a file by file basis including any fragmentation that existed at the time of imaging
Ghost images of NTFS volumes are produced and restored MFT-entry by MFT-entry; on capturing, this means that fragmentation of the source volume impacts the capture performance, a fact that used to be exploited in the benchmarks used by PowerQuest's tools, which work purely at a sector level and do no defragmentation.
The PowerQuest tools would capture (and restore) the image in a single pass over the disk, and so their published benchmarks were taken by carefully synthesizing a volume with maximum fragmentation levels. Because Ghost did work (mostly at image capture time) to gather file data, by doing this PowerQuest could publish benchmarks showing their tool 'was faster' even though in practice it normally wasn't, and the result was not what you wanted for a deployment tool - in the only cases where the PQ tools were faster, the restored volume was just as cripplingly defragmented as the source. So, PowerQuest's toolchain was preferable for backup purposes (where it's ended up in BESR) where captures dominate restores, whereas Ghost was built for and better for deployment (where restores dominate over captures).
Note, by the way, that there are lots of "levels" of NTFS fragmentation; the simplest is fragmented data runs, but there are even more extreme kinds of fragmentation where the $DATA attributes get fragmented across MFT entries. Because the first versions of Ghost that worked with NTFS didn't understand the NTFS structure all that well, it did limit the amount of defragmentation done on the restored volume, and because it worked purely MFT-entry by MFT-entry, it didn't (and still doesn't) try and unwind $DATA attribute fragmentation, but it's gone to various levels of effort to at least put data runs close together.
One particular reason fragmentation mattered to Ghost is the specifics of the mapping pairs used in the representation of non-resident MFT attributes - see http://msdn.microsoft.com/en-us/library/bb470039(v=vs.85).aspx for the details of the delta encoding it uses for data runs. In the earlier versions of Ghost, when it had to lay out data differently due to differences in volume size, this encoding meant the size of the non-resident $DATA attributes changed, and in the worst case could overflow their containing MFT entry (there's an old error message not present in newer versions of Ghost about "attribute translation" which was due to this).
While Ghost still doesn't go the whole way in terms of coalescing the data runs in the $DATA MFT attributes (that would have been preferable, but one of those things limited by underfunding), it now goes to some effort try to place the data runs adjacent to each other, not just for better I/O performance during restore but also because this tends to produce the most compact delta encoding. That's one reason the newer 2.x versions of Ghost could restore some heavily-fragmented volumes that Ghost 8.x and earlier would choke on.
As far as I am aware, the current GSS release is not compatible with the Win 7 version of WinPE (V3).
Actually, it's perfectly compatible with Win7 PE, and indeed just about any version of Ghost ever is - after all, the only thing Vista did to really break compatibility was UAC, and UAC doesn't affect WinPE at all as you're implicitly logged in as LocalSystem.
Putting Win7 into the management environment isn't that hard either, it's something we simply hadn't committed to and done already in the GSS 3.0 environment becuase Win7 PE still really didn't exist at the point when Symantec shut down development, and so we were getting the GSS 3.0 Beta out before putting someone onto that closer to Win7 release before deciding what we'd do. Most likely, we wouldn't have included it because we wouldn't have had enough time to test it before making it the default PreOS, and in particular it wasn't clear whether it's work any better than Vista in small-memory (i.e., 256mb) machines where we had to really strip down Vista to get it to boot.