It is not chained. The data of the columns whose number is > 255 is still stored in the same block provided the block has space.
The real problem is "table fetch continued row " event appears in the statspack report.
Oracle has to do 2 IOs (logical) for the data appears after the 255th column even when all the columns data are stored in one block and the row is fetched via index look up.
However, full table scan will not suffer from 2 IOs.
You can have 1000 columns in a table. In my opinion, restrict the number of columns less than 255 and the performance will be good.
As long as an object has proper storage attributes defined and its row fits within a block, there shouldn't be any issues. Row migration and Row chaining caused either by a row update or inability to accomodate a row within a block can cause waits. You can find details on row migration, row chaining and the specific conditions that cause the "table fetch continued row" wait event, at these links: