"logging" is about storing redo entries for database recovery in case of emergency. Here's a scenario which we can look at from both logging and nologging perpsective

9am: create index MY_INDEX on MY_TABLE
10am: disk corruption, database needs restoring from backup

Logging case:
- while the index was being built at 9am, redo log information was captured for all index blocks created
- at 10am, we restore the database from (say) last nights backup
- we then roll forward our archived redo, which will include the logged index build, and our index comes back

NoLogging case:
- while the index was being built at 9am, NO redo log information was captured for all index blocks created
- at 10am, we restore the database from (say) last nights backup
- we then roll forward our archived redo, which is NO evidence of the index we created. The dictionary entry for the index will be there but the index itself will be basically be "absent"

You would then need to drop and create the index from scratch again

If you *know* you are planning nologging operations, then you could this:

9am: create index MY_INDEX on MY_TABLE nologging
***9:10am: Once the index is built, take a backup of the tablespace/datafiles that hold that index to ensure we have a copy of the index
10am: disk corruption, database needs restoring from backup

This limits your risk to a smaller window of time.

My general mode of operation is - I'll use logging (just to save myself from any hassles) until such point as build runtime performance becomes so critical as to need nologging (and then I'll look at appropriate backup measures to limit exposure)