can't hurt... why not run an experiment, try importing and using it without an index, remove it, create the index reimport and perform the same tasks again...any improvement? if not, nothing was damaged and nothing will deteriote performance wise with one
Actually, you NEVER want to build a table indexes before initial load. This guarantees the worst possible load performance, and will fragment the spatial index (which will be sub-optimal, since the index parameters are best derived from the data to be indexed, after it has been loaded).
In reality, shapefiles will often out-perform an enterprise geodatabase table, especially in unbounded queries (draw all rows), just because the database overhead to support ACID can't compete.
Small subset draw performance for ALL data formats always benefits from reorganizing the features into spatial order, though it may be barely measurable with small tables, it's always present, and in large tables is always significant (and in very large tables can have several orders of magnitude of performance gain vice raindomly organized tables.
There are dozens of variables that go into draw performance, so a "What can be done?" question can only be answered, "Well, it really depends." To generate an answer, you'd need to provide:
There are also render rule optimizations (Are the features being drawn by multiple queries?) and other issues that impact draw performance that have nothing to do with storage format.
It also helps to understand that features are NEVER "loaded into SDE". Features are always loaded into the database through ArcSDE components, as embedded in ArcGIS clients.