You can manage without. You have plenty of Object Oriented options to get to the items.  Or you could use $O over the global to get the IDs (similar to what Extent would do)

I guess it depends on which context you're referring to essential.

If you are working on a pure Cache environment you can probably go without the SQL layer. However, you need SQL to expose data to the world (e.g. reporting tools that can only connect through xDBC layer).

In terms for performance you can always make the case that SQL is slower when compared to direct global access, however SQL provides more "readability" for new (and not so new) developers since SQL is "standard" (or wider spread)  compared to ObjectScript.

My rule is to always chose SQL over direct global access unless the performance requirements can only be met by the latter. 

Can you elaborate on this: "For performance reasons we suggest using Foreign Keys instead of relationships."

My understanding is that Relationships will create the foreign keys (and the relationship table) for you similar as you would do in the relational world:

TableA

AID

TableB

BID

TableABRelationship

AID

BID

FK: AID

FK: BID

The 3 options yield the "same" results, however, depending on needs, one requires more work on your part than the other. With Relationships, for example, Cache automatically handles all referential integrity for you (foreign keys are automatically generated for you). Whereas the other options don't provide that and you're required (depending on your needs) to code  the referential checks (e.g. declare foreign keys). 

You're on the right track,  however, depending on your needs, always prefer a relationship over a "plain" array/list. One of the biggest benefits is the referential integrity you get "out of the box".