I am not sure that I am in a position to disagree with either Jonathan or Greg regarding that OTN thread. Their answers are probably better than the answers I would have provided had I joined that thread.

I noticed in that thread you stated “I thought when oracle joins two tables, which are accessed using full table scan, it will always (??) choose hash join (unless explcitly hinted to use Nested Loop).” In part 4 of this blog article series (and also in this blog article) I showed an unhinted execution plan that showed nested loops and a full table scan, even when suitable indexes existed:

Plan hash value: 2077217387

---------------------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |  1000 |   414K|  1085   (1)| 00:00:14 |
|   1 |  NESTED LOOPS                |              |       |       |            |          |
|   2 |   NESTED LOOPS               |              |  1000 |   414K|  1085   (1)| 00:00:14 |
|   3 |    TABLE ACCESS FULL         | T1           | 10000 |  2070K|    84   (0)| 00:00:02 |
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0018300 |     1 |       |     0   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| T2           |     1 |   212 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("T1"."COL1"="T2"."COL1") 

The above shows a nested loops join between the “large” table and the primary key index for table T2.

In this blog article we also see another case:

Plan hash value: 617224274

--------------------------------------------------------------------------------------------
| Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |             |   100 | 42400 |   303   (0)| 00:00:04 |
|   1 |  NESTED LOOPS                |             |       |       |            |          |
|   2 |   NESTED LOOPS               |             |   100 | 42400 |   303   (0)| 00:00:04 |
|   3 |    TABLE ACCESS FULL         | T2          |   100K|    20M|     3   (0)| 00:00:01 |
|*  4 |    INDEX RANGE SCAN          | IND_T1_COL2 |     1 |       |     2   (0)| 00:00:01 |
|   5 |   TABLE ACCESS BY INDEX ROWID| T1          |     1 |   212 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   4 - access("T1"."COL2"="T2"."COL2")

In the above a full table scan is performed on T2 (the small table) and a nested loops operation is performed on an index for table T2 (the large table).

Was there something else in that thread that you found to be interesting?

That is a lot of SQL and plans to look at
On a serious note, I am not sure if this is any way related to this topic but this reminded me of a case I saw on forums in the past.
http://forums.oracle.com/forums/thread.jspa?threadID=1015916&start=0&tstart=0
The database version in that case was 10.2.0.4 and I clearly remember that I was able to reproduce OP’s results. Jonathan and Greg have provided some classic answers (as always) there. I am not sure if 11g has “fixed” it (I thought of testing it but a) I did not have enough space on my VM and b) got bored of creating so many daily partitions )