Generally speaking ... should join tables (i.e. associative tables) be created as Index Organized Tables (Oracle) , Clustered Indexes (SQL Server) .... or plain old heap tables (with separate indexes on the 2 columns).
The way I see if, the advantages are:
Speed improvement. You're avoiding a heap table look up.
Space Improvement. You're eliminating the heap table altogether, so you're probably saving ~30% space.
The disadvantages:
Index Skip Scan (only applies to Oracle) .. will be faster then a Full Table Scan, but slower then an Index Scan. So searches on the second column of the compound key will be slightly slower (Oracle), much slower (MSSQL).
A Full Index Scan will be slower then a Full Table Scan - so if most of the time the Cost Based Optimizer is doing Hash Joins (which don't take advantage of Indexes) ... you could expect worse performance. (Assuming that the RDBMS doesn't first filter the tables).
Which makes me question whether any type of indexes are really required for Join Tables, if you're predominately going to be doing Hash Joins.
My personal rule-of-thumb is to create two-table associative entities as index-organized-tables, with the primary key constraint being the access "direction" I expect to be more commonly used. I'll then generally add a unique index to cover reverse order of the keys, so in all cases the optimizer should be able to use unique-scan or range-scan access.
Three-table (or more) associative entities generally require significantly more analysis.
Also, the optimizer will use indexes with hash join operations; generally fast full scans, but indexes nonetheless.