When Oracle first introduced segregated data buffers (each sized for a different tablespace blocksize), it opened-up a whole new world of possibilities for the Oracle tuning professional.

Today, multiple blocksizes are used in world-record performance benchmarks, and you can click here to read about real-world applications of large Oracle block sizes.

Going with small blocksizes:

For high-update objects (lots of insert, updates and deletes) many Oracle professionals segregate these into a small data buffer to relieve stress of the DBWR background process.

Random fetches of small table rows can also be segregated into a 2k tablespace so as not to waste RAM data buffers when you are only seeking small rows with single-row fetches.

Going with large Oracle blocksizes:

Robin Schumacher recommends a 32k block size for Oracle index tablespaces to keep the tree structure flat and to facilitate index fast-full scans and index range scans with less I/O.

As a general rules, Oracle professionals seek large blocksizes for indexes and objects that are the target of full table scans (i.e. db_file_multiblock_read_count) because more data can be fetched between physical I/O's. Kevin Loney also recommends large Oracle blocksizes except in high-DML conditions:

"There is only one reason not to use the largest block size available in your environment for a new database: if you cannot support a greater number of users performing updates and inserts against a single block. Other than that, increasing the database block size should improve the performance of almost everything in your application. Larger database block sizes help keep indexes from splitting levels and help keep more data in memory longer."