Another worthy to mention item that could impact the results of the test case, and another one that did not immediately come to mind when I wrote the blog article. For the Oracle instance used in this blog article:

SQL> SHOW PARAMETER OPTIMIZER_MODE
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
optimizer_mode                       string      ALL_ROWS

We could then extend your idea a little to say that introducing ROWNUM into the WHERE clause of the test case script’s SQL statements could also lead to a similar results, see:
http://jonathanlewis.wordpress.com/2010/09/30/rownum-effects-2/
http://hoopercharles.wordpress.com/2009/12/09/sql-%e2%80%93-bad-execution-plan-caused-by-rownum-row_number-is-possible-fix/

Any other ideas regarding what we should test in this test case?

Thank you for suggesting another item that could affect the test case results, and another item to consider if we were trying to help the original poster in the OTN thread. For the Oracle instance used in this blog article:

SQL> show parameter pga
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- -----
pga_aggregate_target                 big integer 400M

I mentioned the size of the table, or more specifically the column descriptions for a couple of reasons. One of those reasons is how the AVG_ROW_LEN for the table affects the costing of an access path (page 11 seems to show its use: http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%2010053%20Event.pdf – but there are probably more recent articles) – should we full table scan or index range scan to access the table data. Another reason I mentioned the size of the tables, or more accurately the size of the selected columns, is how much data will be supplied as input to the next operation in the plan – that likely is not an issue demonstrated in my simple test case script.

Getting back to your point, what if the join column was a 100 byte VARCHAR2 column rather than a numeric column, or multiple columns totalling an average of 200 bytes were the join condition. As you state, the amount of memory available for storing the hash table is an important consideration.