From what I can tell, it has to do with minor accumlated errors in index and view definitions in prior releases. The further back (release-wise) your original database was created, the more likely the chance you will run into an error during the upgrade. The ones I am dealing with were originally created 10+ years ago, for reference.
The Sybase 9 to 11 upgrade (at least during the 5.0 upgrade, have not tested the 4.12 version) performs a "sanity check" by forcing a ton of manual re-builds of the views, indexes, and default table values - so if anything is out-of-whack, you have to correct it before the upgrade script will complete and allow your database to be usable. On average for databases I have converted so far, it is one to two unique errors per database - each of which have taken me between 15 minutes and a few hours to resolve. The issues I have seen most often are corrected by temporarily changing indexes to not require unique keys (note the table so you can clean it up afterwards) and by copying and pasting broken views from a new shell database or a successfully-upgraded one into the database you are upgrading.
At present, our local Micros office insists on upgrading a lab system with a copy of each database so the manual fixes can be documented ahead of time and applied in a timely fashion during the actual migration. Given all of the above, it's definitely a sound decision and saves hair-pulling at 3am.