I'd be more concerned about SPACE Utilisation and Administration TIME rather than PERFORMANCE. The more fragmented your tablesapce, the more space you'll need to store the segments it contains, and the higher the change of processes falling over therfore increase time to fix the issue.
I have a case in which I have > 2000 tables truncated and reloaded each week and their associated indexes (of course are rebuilt). Not all together mind, about 400 each week day. Therefore, truncating and recreating indexes that are different sizes can can cause the process to fail because the associated index with different sized extents live in the same tablespace. Even coalescing doesn't soemtime return enough free space to recreate the object. Therefore leaving the only optioon to expand the tablespace again.
Obviously, maintaining uniform extents is the answer, but I'm just pointing out that the issue with fragmentation is more than just a PERFOMANCE issue. It is also a SPACE and TIME factor in which additional administration is required for fragmentated tablespaces... and thereby elevating my hate of teh COMPRESS=Y optiin in Exports.
Cheers,
OCP 8i, 9i DBA
Brisbane Australia