Oracle's archivelog mode is a safety mechanism whereby Oracle can "roll forward", by applying the "after images" of all changed rows.  It is where the entries in redo logs are saved prior to the point in time where a new incarnation of the log overwrites the previous log.  Internally, Redo is a critical recovery component, and its entries contain changes to data, indexes and undo segments (as well as commit markers and other 'housekeeping' items such as end-of-job and commit checkpoints). 

Archiving makes sure that the redo component is protected.  When in backup mode, some tablespace redo entries are blocks rather than change vectors.  Running in archivelog mode has some significant overhead to an Oracle databases, especially those with high DML activity.  With this in mind, it is important to remember that redo and archivelog mode are two different things.

Oracle archivelog mode was created back in the days when disk failures were common and the ability to "replay" the DML transactions was critical to disk failure recovery.  The decision to run in ARCHIVELOG vs. NOARCHIVELOG mode was a gamble, weighing the additional overhead of managing and archiving the Oracle redo logs, vs. he probability of an unrecoverable disk failure.

However, times change.  Today's disks are far more reliable than ever before, and triple-mirrored disks have a mean-time-between-failures (MTBF) that is expressed in centuries.  We also see hardware-level disk backups that ensure recoverability to a point in time without data loss.

We also see the new Solid State Disks with online backups to tape and disk, and disk-level hot backups that can reliably take incremental backups while he instance is accepting updates.  Some shops are also using Oracle Streams replication and tools such as Quest Shareplex to replicate Oracle databases in real-time, further reducing the need to recover and roll forward from Oracle redo logs.

I have heard of Oracle customers who choose to run their databases in NOARCHIVELOG mode because they are comfortable with their low-level of risk from disk failure, and they take hardware-level backups. 

The vast majority of Oracle databases require ARCHIVELOG mode to ensure recoverability, and no Oracle professional should consider turning on NOARCHIVELOG mode without making management aware of the risks of disk failure (the MTBF from the disk vendor), and the risks of data loss. 

It is important to remember that the need for disk recovery does not come solely from disk failure.  In fact, there are many different reasons for recovery to be required, including such influences as security issues caused by developers working in a production environment or improperly tested code in an application.

The risks of running in NOARCHIVELOG Mode

So what are the risks of running in NOARCHIVELOG Mode?  There are several areas where the archived redo logs would be handy:

Logical Corruption:  In a case where a singe table needs to be recovered.

Table/Index corruption:  A software corruption might occur in a table or index structure.