Whereas, I've been doing ABAP development for 18 years, and my general approach is as follows:
1) If the table is only to be processed through and order doesn't matter:
Use a STANDARD table.
2) If the table has a strange sort order or is required as a parameter that must be a STANDARD table, then use a STANDARD table.
3) If the table is to be READ, define as a HASHED table if there is a unique key. Otherwise, define as SORTED
4) If index operations are required, but you still need READ access, use a SORTED table, preferably with a UNIQUE key.
5) If access to the table is required by more then one group of fields, then define additional keys (later version of ABAP only).
In summary, my choices are - first HASHED, second SORTED, third STANDARD.
I believe it is better programming to use the narrowest most tightly defined data type. The overhead of non-STANDARD tables is minimal, the gains are huge. The cost of refactoring a program what doesn't use a HASHED table and performs badly is greater than the cost of using a HASHED table from the start.