-- Lets create two identical tables emp and emp2

thiru@9.2.0:SQL>create table emp2 as select * from emp;

Table created.

thiru@9.2.0:SQL>analyze table emp compute statistics;

Table analyzed.

thiru@9.2.0:SQL>analyze table emp2 compute statistics;

Table analyzed.

-- They have same number of rows and size. Neither of them have any indexes

thiru@9.2.0:SQL>select table_name,blocks,num_rows from user_Tables where table_name in ('EMP','EMP2');

TABLE_NAME                         BLOCKS   NUM_ROWS
------------------------------ ---------- ----------
EMP                                     4          8
EMP2                                    4          8

-- Lets start with EMP followed by EMP2 . 

thiru@9.2.0:SQL>select count(*) from <B>emp,emp2</B> where emp.empno=emp2.empno;

  COUNT(*)
----------
         8

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=1 Bytes=6)
   1    0   SORT (AGGREGATE)
   2    1     HASH JOIN (Cost=5 Card=8 Bytes=48)
   3    2       TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=8 Bytes=24)
   4    2       TABLE ACCESS (FULL) OF 'EMP2' (Cost=2 Card=8 Bytes=24)

-- as you see above, EMP is processed first here. Join order is EMP to EMP2 . This is expected.

-- Now,lets change the order. this time EMP2 followed by EMP

thiru@9.2.0:SQL>select count(*) from <B>emp2,emp</B> where emp.empno=emp2.empno;

  COUNT(*)
----------
         8

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=1 Bytes=6)
   1    0   SORT (AGGREGATE)
   2    1     HASH JOIN (Cost=5 Card=8 Bytes=48)
   3    2       TABLE ACCESS (FULL) OF 'EMP2' (Cost=2 Card=8 Bytes=24)
   4    2       TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=8 Bytes=24)

-- AS you see above, Emp2 is processed first . The join order is Emp2 to Emp. The CBO did get influuenced by the order specified in the FROM cluase. 
 This is one of those special conditions(all things being equal) where this is possible. I am sure Tom was simplifying things.

-- But when I disturb this 'all things being equal' condition, 
then the order of tables becomes irrelevant .We will get the same join order over and over again.

-- Let me create an index on EMP now 
thiru@9.2.0:SQL>create index emp_idx on emp(empno);

Index created.

thiru@9.2.0:SQL>analyze table emp compute statistics;

Table analyzed.

thiru@9.2.0:SQL>select count(*) from emp,emp2 where emp.empno=emp2.empno;

  COUNT(*)
----------
         8

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=6)
   1    0   SORT (AGGREGATE)
   2    1     NESTED LOOPS (Cost=2 Card=8 Bytes=48)
   3    2       TABLE ACCESS (FULL) OF 'EMP2' (Cost=2 Card=8 Bytes=24)
   4    2       INDEX (RANGE SCAN) OF 'EMP_IDX' (NON-UNIQUE)

thiru@9.2.0:SQL>
thiru@9.2.0:SQL>select count(*) from emp2,emp where emp.empno=emp2.empno;

  COUNT(*)
----------
         8

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=6)
   1    0   SORT (AGGREGATE)
   2    1     NESTED LOOPS (Cost=2 Card=8 Bytes=48)
   3    2       TABLE ACCESS (FULL) OF 'EMP2' (Cost=2 Card=8 Bytes=24)
   4    2       INDEX (RANGE SCAN) OF 'EMP_IDX' (NON-UNIQUE)

-- As you see above, when I have an index on one of the tables, 
I get the same plan(ie a Nested loops join from EMP2 to EMP) irrespective of the order of the tables in the FROM clause. 
This is what you'll observe in most of the cases as the participating tables and indexes will have something or the other different!

thiru@9.2.0:SQL>