There are a great many things in the GSS 2.5 series of GBW that produce that error; insufficient space and >2Gb files are just the most common ones, but there are all kinds of other bugs both in the code which produces ISO 9660 filesystems (which fails if too many files are added to the ISO, for instance when including the DeployAnywhere driver database) and the code which does the SCSI wrangling of the optical disk command set.
[ That's why for 3.0 all that got rewritten completely - writing 50Gb Blu-Ray discs required all the SCSI-layer stuff be done properly to properly understand the differences between, for example, the DVD+RW or DVD-RW write models, and as well I properly implemented ISO 9660 level 3 and Joliet so any number of files of any size could be written. ]
The number of other things which end up producing the same message also includes particular species of existing formats on the disc, for instance, because the existing GBW code doesn't even try to model the different optical disc write models nor support UDF. If you have a +R or -R type disc that has any data on it at all, you can't use it.
So in general, the source of this particular error is impossible to answer - there are far too many cases which will generate it. However, the one thing that's really different in your report from the norm is this:
although same error occurs when trying VFD
That's most notable because there's almost nothing in common between the floppy write (VFD being specialized off the floppy code) and the ISO write - there's basically no code at all shared between the two systems because floppies and ISOs have nothing at all in common - different filesystem, different media model in the code, it's all different. Just about the only thing that *is* shared is the data in the source templates.
Probably the best thing to do at this point is the obvious one: use Process Monitor.
If you get a detailed trace of what the GBW is doing from the start right up to the point where it fails, generally at the end of the trace you'll see some kind of operations issued by the GBW executable which yield a failure at the API level which Process Monitor will capture. That won't always be true when working with real optical disks (as the SCSI pass-through stuff is kinda special) but when writing to a target that's just an ordinary file then everything is plain Win32 APIs which Process Monitor logs just fine.
Going back through the log and looking at the API errors may give you a pretty direct hint as to the source of the problem; if there are API errors, the context of those errors may give a pretty big hint (and of course, since Process Monitor captures the running program's execution state for each call, a Process Monitor trace is a prime source of evidence for the developers to use - when Ghost development was in Auckland it would have been trivial to get such a log examined and an authoritative answer, although now it's a different story).