The strategy is like this.
1. Know the extent sizes of typical segments that are going to be created on a particular tablespace.
2. Use these values to create the tablespace.
3. These default values can be used for typical segments (Tables, Indexes etc).
4. User defined extent sizes can be used if the new segment is going to behave differently ( very small or large size)

I guess, this slves the debate of whether to use tablespace defaults or at segment level values.

To come to the base question...

It is advisable to have size of initial and next extents for tablespaces. The same applies for the newly created tables too.
If the table is created using a direct inserts and expected to be of bigger size, then we should go for a bigger intial extent that is multiple of next extent. This gives minimal ammount of fragmentation.

To remind you guys... The thumb rule is to have the extent sizes as multiples of "db_file_multiblock_read_count"

Offourse, LMT (locally managed tablespace) solves the problem of fragmentation. But, the bulk inserts are slower in LMT compared with DMT (dictionary managed tablespace).

So, it is upto we DBAs to chose the righ extent size and tablespace type to suit our requirements and needs.. This is called human touch...

-nagarjuna