Reasonably effective source code control has been around for a long time, and used in a disciplined way in large projects since long before Final Fantasy VIII started development. For example, the initial import of 4.4BSD-Lite2 source code into CVS to start the NetBSD project was done in July 1992 (growing within a few months to over 6500 files and 2 million lines), and the revision history has been maintained continuously since then.
The problem here is that computer source code is only a small fraction of the assets needed to build a game: you also have all the graphical and sound content, in comparison with which the source code is trivial in size. These are nowhere near as easy to compress as multiple substantially similar versions of text files, and even that aside have generally been too large to keep in a standard source code revision control system without slowing it to a crawl. (There have been attempts at addressing this, such as by Perforce in the mid- to late-'90s, but not all game development houses had the time or money to try to implement such solutions.) Thus, large assets are usually stored separately, sometimes without any real revision control on them at all.
Further, for non-code assets the distinction between "source" and "built" products is less clear. For example, the article to which you linked pointed out:
...but the gorgeous pre-rendered 3D backgrounds look grainy and pixelated. This is because these pre-rendered backgrounds have, for the most part, been lost. All of the backgrounds in FF7, 8 and 9 were created at a far higher resolution than needed then compressed down to fit into 320×240 or 640×480 resolutions.
It would be normal during the development for a particular platform, such as PlayStation, to do the compression and downscaling once and always use that product when doing a build, rather than spend the extra time and disk storage to do the compression and downscaling with every build.
Disciplined use of source code control was not truly widespread in the industry in the '90s anyway, and that in combination with the particular problems and barriers posed by relatively massive game assets and the generally high pressure of game development schedules meant that most games development tended to take an ad-hoc approach without a lot of effort and expense put into archiving.