Both read committed and serializable disallow "dirty reads", so that when you select from a table you don't see anyone else's uncommitted transactions.
Serializable offers additional features that make transactions seem to happen in a specific order, even though in reality they are in progress simultaneously. Serializable offers "repeatable read", which ensures that if you select the same rows a second time in your transaction you will not see updates that were committed after your first select. Similarly you are guaranteed that a second select won't return new rows that weren't in your first select.
The serializable isolation level offers nice features, but comes at a cost of higher overhead. That's probably why Oracle chose read committed as its default. It's up to the programmer to design a transaction and know whether to increase the isolation level to serializable.
